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

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

Потому что это легче всего понять читателю. «Ясность - это не то же самое, что краткость», - пишет Брайан Керниган в книге Практика программирования. Часто более чистый код будет короче. . . но может быть и дольше. . . правильный критерий - простота понимания ».

Четкое письмо также свидетельствует о нашем мышлении. Писатель Уильям Зинссер говорит об этом лучше всего: «ясное мышление становится ясным письмом; одно не может существовать без другого ».

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

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

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

Кто угодно может сделать что-то сложное. Гораздо сложнее взять что-то сложное и сделать его ясным и значимым. Вот шесть способов сделать это:

1. Напишите осмысленные имена классов, функций и переменных.

Имена, которые мы выбираем в коде, который мы пишем, оказывают такое влияние на читаемость и смысл.

Например, однобуквенные имена переменных могут сбивать с толку или вводить в заблуждение. Читатель может не осознавать, что представляет собой единственная переменная t, поэтому ему приходится предполагать, исходя из контекста. Подобные предположения могут стать верным пути к катастрофе. Столь же сбивает с толку, когда имя переменной используется во множественном числе, тогда как оно должно быть в единственном числе (или наоборот). Представляет ли переменная множество элементов или один элемент?

Трудно написать осмысленные имена. Книга Стива МакКоннелла Code Complete предлагает отличные советы по именованию:

«Опишите словами, что представляет собой переменная. Часто это утверждение само по себе является лучшим именем переменной ».

Поэтому спросите себя: «Что представляет собой эта переменная?» По моему опыту и к чести МакКоннелла, ответом на этот вопрос часто является наилучшее имя переменной.

2. Рефакторинг.

Многие писатели проводят большую часть своего времени за редактированием. Одно дело - запечатлеть слова на бумаге. Другое дело - иметь в них смысл.

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

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

3. Прочтите свой код вслух.

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

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

4. Создайте контрольный список программирования.

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

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

5. Решив проблему, изучите код других людей, решавших ту же проблему.

Мы не должны просто писать код. Мы также должны быть обширными читателями.

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

Осведомленность может быть отличным учителем: простое знание хорошего и плохого кода может помочь нам лучше его писать.

LeetCode и Exercism - отличные ресурсы для решения проблем, потому что оба предлагают решения сообщества, на которых можно учиться.

6. Прочтите книгу Уильяма Зинссера «О хорошем письме».

Книга Зинссера предназначена для писателей прозы, но многие из его принципов применимы к нашей работе как писателей кода. В конце концов, авторы прозы и кода занимаются одним делом: четко общаться.

Программист и писатель: amymhaddad.com | Programmerspyramid.com | Я пишу в Твиттере о программировании, обучении и продуктивности @amymhaddad

Первоначально опубликовано на amymhaddad.com.