Стандарты кодирования — залог хорошей сопровождаемости проекта

Любая командная разработка может быть эффективной только в том случае, если участники команды имеют общее видение. Иначе разработка начинает напоминать басню Крылова «Лебедь, Щука и Рак».

Если над проектом работает команда, а не один-два разработчика, то обязательно должен быть стандарт оформления кода (его еще часто называют стандартом кодирования или стилем программирования). Тоже самое касается и аутсорсинговых компаний, в которых проект может передаваться от одного разработчика к другому, и проектов «на вынос», которые передаются на поддержку и сопровождение «во вне», да и вообще любых проектов, которые будут существовать больше нескольких месяцев и скорее всего будут рано или поздно модифицироваться.

Стандарт кодирования — набор правил и соглашений, которые описывают базовые принципы оформления программного кода, используемого совместно группой разработчиков. Цель использования стандарта — упрощение восприятия программного кода человеком, сокращение нагрузки на память и зрение при чтении программы. Бонусом к этому идёт возможность эффективного использования сравнений в системе контроля версий — разный стандарт оформления кода «ломает» нормальный процесс работы с diff'ами, так как подсвечиваются все изменения в оформлении, а не только в бизнес-логике.

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

Как правило, это всё автоматизируется на уровне IDE (программной платформы, которая служит для написания кода). Программист может писать код как ему удобно, а IDE может за него автоматически форматировать написанный программный код согласно заданным правилам.

Использование стандартов кодирования — это экономически целесообразный подход, так как чем быстрее программист может понять написанный ранее код, тем меньше оплачиваемого времени он на это потратит. Да и для душевного здоровья программистов это полезно — практически все программисты не любят читать чужой «говнокод» в смутной надежде понять задумку его автора и разобраться с фактически заложенной в него бизнес-логике (нередко бывает, что задумка и фактическая реализация — это «две большие разницы»). Разумеется, что правильное оформление не гарантирует «красоту» реализации, но значительно ускоряет понимание.

Стремления к красоте реализации и правильности программной архитектуры тоже реализуемы на уровне соглашений — в этом очень помогает соблюдение принципов программирования, например: DRY, KISS, YAGNI, SOLID.