Хороший код: писать так, чтобы потом не было мучительно больно

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

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

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

Зачем писать хороший код?

Интереснее было бы ответить на противоположный вопрос, так как преимущества понятного кода очевидны. Он позволяет:

• новым сотрудникам разбираться в незнакомых проектах;
• членам команды эффективно взаимодействовать друг с другом;
• легко вносить небольшие правки;
• относительно быстро перестраиваться под изменившиеся требования заказчика;
• заменять технологии без опасения, что все развалится.

На хороший код достаточно просто посмотреть, чтобы понять основные принципы его работы. А как его написать? Вашему вниманию, 5 секретов человекопонятного кода.

Сначала думать, потом делать

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

Документация и самодокументация

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

1. Имена должны объяснять значение переменной или суть метода. Лучше пожертвовать краткостью, чем понятностью.
2. Для именования свойств подходят существительные.
3. В названиях функций лучше использовать глаголы, отражающие логику.

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

Объяснить можно и нужно нестандартный подход к задаче. Разработчикам, которые будут поддерживать проект, будет полезно узнать, почему создатель не пошел проторенным путем. Возможно, с типовым решением возникли какие-то проблемы. А может быть, существует неизвестный внешний фактор, влияющий на выполнение программы.

Пробелы – это тоже код

Хороший код должен быть читабелен и понятен с первого взгляда. Следует четко отделять друг от друга разные контексты и методы.

Спор между "пробельщиками" и "табуляторщиками", очевидно, вечен. Однако, и те, и другие правы в том, что стремятся структурировать свой код.

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

Программа имеет огромные возможности настройки при помощи файла конфигурации.

  {
    "asi": false,
    "expr": true,
    "loopfunc": true,
    "curly": false,
    "evil": true,
    "white": true,
    "undef": true,
    "indent": 4
  }

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

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

Почти все современные редакторы кода имеют встроенные системы проверки синтаксиса и расстановки отступов.

Не умничайте!

Очень умные программисты всегда обеспечены работой. Ведь кроме них никто не понимает, что происходит в коде, даже если это сторонний код.

// Какой-то массив строк
var myArray = ['hello', 'something', 'awesome']; 

if (~myArray.indexOf('hello')) {
  // когда вызывается этот код?
}

Можете ли вы объяснить, что делает эта тильда? Если да, вы, конечно, молодец. Но как вы думаете, сможет ли ваша команда?

То же самое можно написать по-другому:

// Какой-то массив строк
var myArray = ['hello', 'something', 'awesome']; 
if (myArray.indexOf('hello') !== -1) {
  // Стало немного понятнее, правда?
}

Или даже так, если использовать библиотеку Underscore:

// Какой-то массив строк
var myArray = ['hello', 'something', 'awesome']; 
if (_(myArray).contains('hello')) {
  // Теперь предельно ясно!
}

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

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

Специфика языка

Используйте устоявшиеся выражения конкретного языка – идиомы. Зачастую они понятнее, проще и эффективнее аналогичных конструкций. Любой гид по стилю содержит "хорошие" и "плохие" образцы кода. Вот, например, фрагмент из Ruby Styleguide:

arr = [1, 2, 3]

# bad
for elem in arr do
  puts elem
end

# good
arr.each { |elem| puts elem }

Ruby-программисты предпочитают конструкцию each циклу for. Поэтому для них хороший код - это второй пример.

Правила хорошего кода

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

А вот вам 10 принципов хорошего кода, и бонусом еще 5 принципов сверху :)

Обязательно проверьте, улучшилось ли качество ваших программ.

А что думает о хорошем коде Линус Торвальдс?