Перевод статьи Vinicius Brasil «Tips From The Book Every Programmer Should Read».
Программист должен не только уметь писать код. Он должен уметь писать хороший и поддерживаемый код. Есть одна книга, настолько полезная для программистов, что компании платят своим работникам за то, чтобы те ее читали.
Написание кода, который смогут понять другие программисты, это тяжелая задача. Когда вы пишете ПО, вы должны думать не только о том, сможет ли машина прочесть ваш код, но и о том, смогут ли его читать люди.
“Любой дурак может писать код, понятный компьютеру. Хорошие программисты пишут код, который могут понять другие люди,”
— Мартин Фаулер.
Эту книгу написал Роберт Сесил Мартин (“Дядя Боб”), называется она «Чистый код: Создание, анализ и рефакторинг» (англ. «Clean Code: A Handbook of Agile Software Craftsmanship»). В книге говорится о программировании, ориентированном на читателя кода. Этим читателем может быть:
- сам автор кода в будущем;
- его коллега;
- машина.
Вы должны писать такой код, который смогут понять и с которым смогут работать все трое.
Даже плохой код может функционировать. Но если код не чистый, он может поставить организацию разработки на колени. Ежегодно бессчетное количество часов и внушительное количество ресурсов теряются из-за плохо написанного кода. Но так не должно быть.
Но как писать чистый код? Я перечислю пару принципов, которые вам помогут (и убедят читать статью дальше).
1. Пишите осмысленные имена
Переменные, классы, функции и методы должны именоваться семантически. Не делайте сокращений. Ваши имена должны что-то означать.
// bad :( def dvd(v1, v2) return v1 / v2 end res = dvd(10, 2) // good :) def divide(dividend, divisor) return dividend / divisor end quotient = divide(10, 2)
Внеся в свой код больше семантики, вы сможете понять его, когда в следующий раз возьметесь за редактирование.
Помимо осмысленности, имена должны быть удобны для поиска, например:
// bad :( wait(foo,
86400000
) // good :) MILLISECONDS_IN_A_DAY = 86400000; wait(foo,
MILLISECONDS_IN_A_DAY
)
2. Не добавляйте ненужный контекст
Например, если вы пишете метод или поле внутри класса, вам не нужно ссылаться на контекст класса в имени метода/поля.
# bad :( class Person property :person_name end # good :) class Person property :name end
3. Позвольте вашему коду говорить
Хороший код важнее комментариев. Это правило. Комментарии необходимы, но если ваш код сам себя поясняет, вам не понадобятся комментарии.
Комментарии могут быть злом
Я в этом уверен…
# always returns true def available? return false end
Код с комментариями может быть тяжел для чтения
При быстром просмотре кода строка с комментарием может все спутать.
employee.work boss.promote(employee) # employee.party employee.work
Почему вам стоит прочитать «Чистый код»?
Программисты проводят больше времени за чтением кода, а не за его написанием. Это факт. Чтение кода может быть запутанным, если кодовая база плохо написана или устарела. Для уменьшения путаницы и потерь времени некоторые компании платят своим работникам за чтение этой книги.
Обучая программистов хорошо писать ПО, «Чистый код» создает огромную группу программистов, заботящихся о том, что они пишут, и о тех, кто будет это читать.
Помимо семантики Мартин также рассказывает об обработке ошибок и о том, как нужно читать код.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
