Попроси программиста проверить 10 строк кода, он найдёт 10 проблем. Попроси его проверить 500 строк кода, он скажет: "выглядит норм".

На ревью кода надо отправлять небольшие наработки. Чем больше фрагмент кода для ревью, тем сложнее дать обратную связь. Либо легче — можно скипнуть внимательный анализ и просто проверить работоспособность, совершенно не вдаваясь в детали. Но польза от такого ревью невелика.

Как научиться писать хороший код? Прочитанное в книгах совсем не сразу преобразуется в ваш опыт. В разработке огромный пласт знаний образуется в результате практики написания и, что более важно, чтения чужого кода. Читайте чужой код, господа — это самый быстрый способ роста скилла разработки. Если код хорош — то вы научитесь как надо писать. Если код плох — вы увидите, как писать не надо, и сможете дать обратную связь (если вас об этом попросили, прошу заметить).

#procode #devfm

Нельзя использовать goto

Часто говорят, что goto плох. А собственно, почему?

В ассемблерном коде на машинном уровне все управляющие конструкции (if, while, for и другие) преобразуются в набор команд с безусловным переходом jmp. А такой переход — самый настоящий goto. То есть ты весь такой изящный во фраке пишешь циклы, а наглый компилятор/интерпретатор выкидывает всю красоту и делает goto.

Так почему же сам goto является признаком плохого кода, если он на самом деле везде?

Ответ кроется в умении сохранять контекст. Человек может в голове держать 5-9 сущностей, больше не получается. Поэтому придумали функции, и придумали держать их небольшими — для снижения когнитивной сложности. Конструкция if переведёт тебя в одну из веток ниже, циклы for и while выполнят тело цикла или выбросят за его пределы. Команда goto сложность привносит — прыжок может быть куда угодно. А повышение сложности всегда приводит к росту числа ошибок.

Ну а ещё из-за goto может напасть велоцираптор.

#procode #devfm

— Без требований программирование представляет собой искусство добавления багов в пустой текстовый файл
— Тесты позволяют улучшать API
— Наличие "и" в описании функции — это плохо
— Магическое число 7
— Важность умения запускать код без IDE
— Мой любимый git add -p

Полезные и не очень советы в статье Чему я научился на своём горьком опыте (за 30 лет в разработке ПО). Какие-то пункты устарели, какие-то не универсальны, с какими-то я не согласен.

Не забывайте, что в комментариях можно найти альтернативные точки зрения на разные вопросы, например, на отладчик и прочие инструменты.

Кстати, пример с getUserMessage(userId, true) в питоне решается именованным параметром getUserMessage(userId, retrieveFullMessage=true)
#procode

Месяц назад мы обсуждали, что можно сделать с неработающим кодом. Два дня назад своё видение дебага и отладки раскрыл канал Диджитализируй в ролике Кладём баги на лопатки (24 минуты). Он касается следующих тем:
1. локализация проблемы
2. изучение проблемного участка с помощью отладчика или логгирования. Рассматриваете пример логгирования endpoint-а вебсервера
3. тезис "не доверять ни одному фрагменту кода"
4. бан фразы "у меня всё работает"
5. рассуждения о коде как структуре

На разобранном примере кода с добавлением логгинга в связи с нехваткой времени куча недоработок:
— можно настроить, чтобы имя функции само выводилось в логгере, а не вписывать руками
— непонятно, где какие уровни логгера ставить. У него везде debug
— начиная с python 3.8, в f-строках можно писать f"{var=}" вместо f"var = {var}", тогда будет выведено var=значение

#youtube #procode