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

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

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

#procode #devfm

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

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

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

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

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

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

#procode #devfm