Comments 32
Меня вот позабавило. Особенно мне понравилось
const PI = 3.14 // Число Пи, округлённое до двух знаков после запятойMath.PI для слабаков, только свои константы, только хардкод!
Используйте понятные имена переменных и функций
function averageArray (array) {
Используйте максимально короткие и при этом максимально информативные имена.
function average(array)
Пишите хорошую документацию к своему коду
Только если код нельзя написать читабельным или есть необходимость предостеречь потомков о каких то неочевидных вещах. В остальных случаях пишите читабельный код без комментариев.
4. Подумайте об использований правил Сэнди Метц
Есть только 2 правила, которые работают всегда:
1. Код должен делать то, что должен.
2. Код не должен делать то, что не должен.
Все остальные правила применяемые в тупую, ничего кроме ущерба не приносят.
6. Помните о принципе DRY
Есть только один принцип: код должен работать. Если вы будете ему следовать, никто никогда не спросит, каким принципам и правилам вы следовали.
Можно ли сделать его более читабельным? Не всегда, есть сложная логика, которую нельзя сократить, не сократив функциональность. Примерно, как в математике, есть сложные формулы, которые можно сократить до более простых, но так же есть сложные формулы, которые нет. Так и здесь, есть сложный код, который возможно перекроить десятком способов, но сложность не исчезнет.
Цель, что бы код работал, все остальное средства достижения цели, как например читабельный код с большей вероятностью будет работать хорошо, но не это цель.
Под работал подразумевается, он делает то что надо и в нем есть ровно 0 багов.
Кстати, что из этих правил специфично именно для JS?
Документировать нужно только если код делает чтото непонятное, страшное и неочевидное.
«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте» ©
Все мы знаем последнюю цитату, но она к коментариям не относится. Опыт показывает что коментарии устаревают после первого же рефакторинга. Т.е. они не то что бесполезны, они вводят в заблуждение. Редко кто читая коментарий проверяет что делает функция.
Ну так и я не про комментарии, а про документацию в коде. То, из чего потом можно сделать swagger или wiki-странички с помощью различных инструментов. И как раз такие докстринги и позволяют поддерживать документацию актуальной.
Примеры:
- Докстринги для типов и полей доменных объектов будут служить глоссарием для программного модуля. В противном случае это будет вынесено в какой-нибудь вордовский файл или wiki. И через несколько итераций полностью потеряет связь с реальностью.
- Докстринги к экспортируемым функциям будут служить дополнительным описанием контракта модуля. Иначе, чтобы понять что делает модуль нам нужно либо прочитать его код, либо прочитать его юнит-тесты.
- Из докстрингов к props для React-компонента можно слепить сайт с документацией и примерами использования.
Просто я искренне не понимаю, почему я должен держать в голове какие-то сложные особенности предметной области, если я могу вынести их в докстринги. Облегчив тем самым жизнь и моим коллегам, и себе в будущем. А кому не нравится — все нормальные IDE позволяют эти докстринги свернуть.
Методы и функции не должны быть длиннее 5 строк кода.
Да ладно вам, разве это возможно?)
Бывает, что code-style не приемлет египетских кавычек.
function someFunction(something)
{
if(something)
{
handleOne();
}
else
{
handleTwo();
}
}
Простейшая функция с if-else
вышла в 11 строк :)
Хотя согласен, что 5 строк всё равно жесковато. Я лично для себя вывел следующие пороги:
а) ~10 sloc — стоит подумать о декомпозиции, вполне возможно, она тут уместна;
б) ~30 sloc — декомпозиция нужна с вероятностью 99%.
Если задаться такой целью, то конечно можно писать методы в 5 строк. Вот только станет ли лучше: короче и понятнее. Вероятно нет.
// это мост.
myFunction (arg)
или
myFunction( arg )
а не о стиле программирования
Или просто падать с маловразумительным сообщением?
7 рекомендаций по оформлению кода на JavaScript