Как в js принято писать логические условия?

Рейтинг: 1Ответов: 1Опубликовано: 01.10.2014

Я привык писать так -

var array = [1, 2, 3];

if( array.length > 0 ){}

var obj = {};

if( obj != undefined ){}

И не пишу сравнение только в том случае, если свойство представляет тип boolean.
Но раз слышал, что в js не принято писать так, как в коде выше. Это правда?

javascript
Источник: Stack Overflow на русском

Ответы

▲ 3Принят

Всё-таки отвечу.
Да, есть такая штука в каждом сформировавшемся языке программирования - coding convention, которая описывает предпочтительное форматирование кода, и, иногда, разбор частых паттернов. Чаще всего это просто документ, однако в нем описывается самый базис, а, кроме документа, есть еще и негласные соглашения. Итак, зачем она нужна?

  • Когда команда девелоперов работает над одним проектом, переход от одного форматирования к другому вызывает фрустрацию (иначе не назовешь). Несмотря на то, что это простое психологическое явление и для победы над ним необходимо простое усилие воли, зачастую оказывается проще обговорить правила заранее. Эта внутрипроектовая конвенция может не иметь ничего общего с конвенциями "за бортом", как, например, замечательный документ от вордпресса, описывающий ровно противоположное PSR.
  • Когда ты понимаешь, что работаешь ты один, но у тебя есть привычка а) постоянно менять свое форматирование, просто не следовать единому стилю и даже не иметь его и б) беситься, когда тот стиль форматирования, с которым ты работаешь, не соответствует твоему текущему настроению и погоде за окном. По большому счету, это тесно пересекается с первым пунктом.
  • И, конечно, OSS. Опенсорс - это восхитительная и свободная штука, но она реально работает только в том случае, если все возможные разношатания отсекаются. При разработке OSS либо ты пишешь непопулярную штуку, либо следуешь конвенции проекта (а т.к. круг девелоперов не ограничен, и они могут присоединиться в любой момент, и им бы до ужина пулреквест написать, а не с правилами добавления кода знакомиться - конвенция проекта по факту приравнивается к конвенции всего языка в целом), либо в коде начинается (извините, мне правда очень стыдно) ужас, с которым никто не хочет сидеть и разбираться, и проект очень быстро тухнет.

Таким образом, при работе в одиночку можно использовать то форматирование, которое нравится. По своему опыту скажу, что пересаживаться на общую конвенцию оказалось легче, чем я думал, и дополнительным плюсом будут всякие настроенные на эту конвенции утилиты по анализу кода, которые подскажут, где чего не так, бонусом будет распирающая гордость за то, что каждая скобка в коде выверена идеально. Но, опять же, при персональной разработке можно хоть писать код справа налево, переворачивать и выполнять eval'ом - все равно никто никогда не увидит.

Что до динамически типизированных языков с нестрогим сравнением - я лично предпочитаю все то, что правильно скастуется в булеан оставлять кастоваться в булеан. Это занимает меньше места, разница между операциями будет минимальна, это не заставляет задерживаться на простом if глазами. Что конкретно до JS - тут есть проблема с отсутствием единого общепризнанного стандарта, насколько знаю, обычно обращаются к стандарту, выложенному гуглом. Он довольно однозначно предписывает не проверять тип, если проверяется общая провальность переменной. В случае, если пустая строка, - это все равно наличие ввода, а null - это ненайденный источник ввода и вообще его отсутствие, тип (или конкретное значение), конечно, проверять надо.
У меня всё.