Советы из книги, которую должен прочесть каждый программист

Перевод статьи 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]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх