Три главные ошибки новичка

Всем снова привет. В этом посте я разберу наиболее частые ошибки в написании кода новичками. (сам таким был, и остался)

Все главные ошибки сводятся к противоречию основным правилам написания кода в командных проектах.

Правило #1: Код пишется людьми для людей.

Первое, что бросается в глаза у новичка, так это то, как он называет переменные.

Да, несомненно круто, когда ты знаешь для чего у тебя у в коде объявлено «q,d,k,j,y,b,c,x,r,p,n:integer», но дай почитать ты такой код другому человеку, и если он тебя не покалечит, то он тоже не слишком хорош сечет.

Компилятору в принципе плевать как ты называешь переменную, а вот человеку нет.

Скажем, inpstr и s для компилятора не имеют разницы, а вот человек, которые это читает, сразу поймет для чего эта переменная. Тоже самое относится и к названию методов и классов.

Правило #2: «Ничто не повторяется дважды»(Хроники Нарнии, Принц Каспиан)

Если ты видишь, что в твоем коде есть повторения, скажем один и тот же кусок кода повторяется более одного раза, то правилом хорошего тона является вынести этот кусок в отдельную функцию. Более того, это весьма улучшает читабельность кода.

На ранней стадии эволюции, я постоянно использовал цикл в цикле, в цикле с if, который в другом цикле. Так вот, за первое появление сего в коде проекта, я был лишен премии. Хотя там это и было оправданно, но разбираться особо не стали. Там было повторение одного и того же кода несколько раз, после вынесения которого в отдельный метод, все претензии были сняты.

Правило #2.5: Всему свое место или как отступы спасли не мало жизней.

Когда только начинаешь прогать расположение кавычек, операторов, пробелов почти не имеет значения. Когда читаешь код в первый раз все хорошо. На прогах где меньше 40-ка строк вообще все не плохо смотрится, но когда код содержит более 200 строк, понимать его становится крайне проблематично, без достойного форматирования.

Вот наглядный пример:

Исходный код screenshot_48

И тот же код с отступами и форматированием

screenshot_49

Если бы вы залили на сервер исходный код этого примера таким какой он был до рефакторинга, то за сломанную вашими коллегами (вам) руку не стоит винить никого, кроме себя

Правило #3:Чем проще код, тем лучше.

Когда пишите код, делайте его как можно проще, понятнее. Если есть возможность написать два разных цикла для выполнения двух операция, сделайте это. Поверьте, отлаживать 2 цикла намного проще, чем один большой. Позднее все же можно их объединить, если вопрос оптимизации стоит очень остро, но обычно до этого редко доходит.

Еще можно взять за правило разбивать код на мелкие мелкие части. Чтобы каждая из них делала какую-то одну вещь и не зависела от других частей программы.

Примечание: Данные советы прекрасно работают в командных проектах. В полевых условиях же, будь то олимпиады или хакатоны о данных правилах обычно забывают, ибо на качество решения задачи они никак не влияют. Это косметические приемы направленны на работу в команде и требуют определенных навыков и дополнительного времени, которого в полевых условиях нет и быть не может.

maxspt

Оставить отклик

Ваш адрес эл.почты не будет опубликован.