Код программы может быть написан по разному. Абсолютно по разному можно понимать и правильность кода. Ведь один и тот же функционал можно написать несколькими вариантами. Каждый из таких вариантов может быть по своему как хорош, так и полон недостатков. Поэтому, точно утверждать, что какой-то конкретно написанный фрагмент кода написан неверно, бывает иногда сложно.

Код соответствует требованиям

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

Поддержка кода

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

Скорость программы

Скорость работы программы тоже не маловажный атрибут хорошего кода. Трудно работать с программой, которая очень медленно работает, постоянно зависает и заставляет тебя чего-то ждать. Но не нужно брасаться и ускорять все подряд. Вовсе нет. Сперва нужно понять и разобраться, какие участки кода наиболее часто используются программой, почему эти участки медленные и как именно их оптимизировать для повышения скорость работы программы.

Маскировка ошибок кода

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

Излишнее комментирование

Программа должны нести в себе понятно написанный код. Для этого необходимо называть переменные и методы понятными именами, чтобы при прочтении кода, можно было понять, какое действие выполняется. Если же этого недостаточно, то нужно прокомментировать участок кода и пояснить, что он делает. Однако, зачастую не стоит увлекаться излишним комментированием. Необходимо это делать там, где действительно нужно. Ведь если вдруг вы измените какой-то участок кода, а комментарий забудете и оставите старый, то его смысл потеряется, через некоторое время комментарий может ввести вас в заблуждение и вы можете запутаться. Поэтому, не стоит описывать буквально каждую переменную или условие. Достаточно описать, что именно делает тот или иной метод, за что отвечает действие или какой-либо модуль.

Оптимизация раньше времени

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

А что вы думаете по этому поводу? Где следует проводить грань различия между правильным и неправильным кодом?