Comments 64
Ещё с пятой колонной разобраться не успели, уже седьмая на помощь спешит…
Гм. Вечером в понедельник шутливый комментарий никого не привлёк, утром во вторник в топик на Хабре заглянули те, у кого ещё не проснулось чувство юмора, и наставили ему минусов. Это была ирония, основанная на игре слов, товарищи, и-ро-ни-я :) Выдыхаем! :)
UFO landed and left these words here
Точки с запятой не нужны в 99.99% случаев.
Обычно, если вы склеиваете файлы и в вашем файле код начинается с открытой скобки — это единственное место, где точка с запятой необходима «на всякий случай». И всё. Все остальные места необходимости точки с запятой очевидны для вашего кода (которые, как правило, отсутствуют вовсе).

Ставить их всегда — это как ходить под зонтом в пределах крыши — а вдруг что-то на голову свалится.
UFO landed and left these words here
Вы правы, если минификатор сам будет расставлять точки с запятой, а если не будет? Лучше «ходить с зонтом под крышей».
У минификаторов вообще другой взгляд на мир, и они прекрасно понимают код без точек с запятыми. Некоторые, в погоне за размером, вообще перестраивают код с обильным использованием запятых.
Если минификатор умеет только удалять пробелы и переводы строк в коде — то это фиговый минифактор.
Мне свалилось. Как-то из-за пропущенной точки с запятой образовалась труднонаходимая ошибка.
Если понимать, где их ставить необходимо, где целесообразно «на всякий случай» (исключительно для защиты от кода файлов, которые вы не пишете, если они склеиваются), а где не нужно вовсе — ничего не свалится.
Касательно стайлгайдов, где рекомендуется ставить везде — новичкам сложно понять где их нужно ставить сходу, и предостережение перерастает в базовый стиль кодирования.
UFO landed and left these words here
Ок, вместо дополнения просто оставлю это здесь: www.quizful.net/post/semicolons-in-javascript-are-optional-mmarohnic
Да, там где-то внизу есть список: (, [, +, -, /, но если ваш файл первой строчкой начинается с чего-то, кроме открывающей круглой скобки — это, по меньшей мере, странно, и про стиль кодирования тут говорить уже глупо.
Про очевидные места в вашем коде (не в начале файла) имелись в виду скобки (в том числе и квадратные) и, преимущественно, +, может быть ещё и -, как правило в строках --i, ++i.
UFO landed and left these words here
Вот ещё в догонку: habrahabr.ru/post/111563/
Там неплохо разложены по полочкам все заблуждения и опасные места. В том числе break, continue, return — но это, как по мне, уже проблемы стиля кодирования, где такое допускается.
Конечно, можно писать точки с запятыми везде, где нужно и не нужно, и это, может быть, убережёт вас от лишних проблем. Но это не является необходимостью, правилом или ещё чем-либо таким магическим и единственно-верным. По моему, если в вашем коде есть места, где без точек с запятыми поведение программы непредсказуемо — то проблема в другом.
Сюда ещё хотелось бы добавить фигурные скобки и «ставьте их везде во избежание проблем с отступами». Мне нравится coffeescript отсутствием скобок и обязательством ставить отступы. Он как бы обязывает обращать много внимания на важность отступов, и, если бы столько внимания было уделено отступам в js, то никогда не возникло бы проблем с фигурными скобками в однострочных конструкциях условий и циклов.

То есть, проще говоря, проблема не там, где кажется.
Ну и да, ещё после i++,i--, но прежде всего стоит подумать, зачем оно такое в коде, если оно лежит вне условия for, где точки с запятыми обязательны. А если оно у вас необходимо, я уверен, что вы вполне понимаете где и зачем ставить точки с запятыми.
Отличный аргумент, беру на вооружение!

Если у вас возникают проблемы при склейке или минификации файлов из-за забытого семиколона, значит вы используете кривой инструмент написанный человеком, плохо разбирающемся в семантике языка, который он взялся преобразовывать. Использование кривых инструментов — основной источник ваших проблем, а не раздолбайство программистов.

Для новичков же есть более полезное правило, чем «ставьте везде семиколоны». Звучит оно так: Если строка не является продолжением предыдущей, то начинайте её с ключевого слова или имени объекта

Проиллюстрирую примером, проблемного для глупого склейщика кода:

(function(){
    alert('a')
}())

(function(){
    alert('b')
}())

Глупый склейщик соберёт что-то такое:

(function(){
    alert('a')
}())
(function(){
    alert('b')
}())

И это не будет работать. Более толковый склейщик сгенерирует нечто вроде:
;//a.js
(function(){
    alert('a')
}())
;//b.js
(function(){
    alert('b')
}())

Но если придерживаться предложенного мной правила, то даже глупый склейщик ничего не сломает:
void function(){
    alert('a')
}()
void function(){
    alert('b')
}()

К сожалению, многие писатели мануалов, учебников и стайл-гайдов не в курсе существования оператора void.
Как человек, недавно ломавший себе руку, могу с уверенностью сказать — спину чесать удобней не станет.
К сожалению могу обосновано (вывих) подтвердить: Не станет.
Я гуманист и сочувствую всем повредившим руку.
Единственного, кого мне не было бы жалко, — это того, кто разрешил не ставить семиколон в JS.
Хорошо, что Eclipse считает так же и предупреждает.
> К сожалению, многие писатели мануалов, учебников и стайл-гайдов…
Не учебников, а туториалов!
Райтеры туториалов не в курсе экзистенции…
Пример с appendTo/prependTo немного не верный. Цепочки вызовов всё же лучше — они и компактные и читать приятнее, а внедрить логику выбора функции всегда можно:
 messageProto
    .clone()
    .text( text )
    [ above ? "appendTo" : "prependTo" ](document.body)
    .fadeIn()

И вообще, тема со стайл гайдами довольно персональная и абсолютной истинны здесь быть не может, лишь советы — за что спасибо.
Проще метод добавить, который сам внутри принимает решение чё делать.
Если аргументы разные, то это зачастую значит, что и методы выполняют разные смысловые действия, тогда лучше так не группировать.
1. Цепочки сложнее в отладке.
1.1. Из-за отсутствия переменных вы не можете посмотреть в дебаггере где какое состояние.
1.2. Вы не сможете поставить точку остановка на середину строки, а при исполнении «по шагам» не будете видеть в каком месте сейчас находится интерпретатор.
2. При усложнении логики у вас получится лапша в одну строку.
3. Можете забыть про автодополнение в IDE и сттатические варнинги при вызове несуществующего метода.
4. Некоторые виды логики нельзя выразить в виде экспрешенов. Например, когда в одном случае нужно два метода вызвать, а в другом один. Или с разным числом и типами параметров. Или в цикле. Или когда нужно временно сменить контекст (я в курсе про костыль в jQuery api.jquery.com/end/)
//cc garex

Смысловой контекст — вот что имеет значение. Для простого выражения из примера делать отдельный метод нет смысла. Поэтому я сказал, что пример не корректный… Если будем говорить о других более сложных примерах, то `clone/text` нужно заменить на метод `create` с явным созданием элемента (не clone). Вместо `appendTo/prependTo` более гибким решением являются placeholder элементы. Если будем ещё усложнять то тогда уже играют большую роль фреймворки, которые за нас многое что сделают и помогут организовать логику. Поэтому >2 и >4 не релевантные.

>1: Цепочки разумеется сложнее в отладке, но опять же из примера на `clone/text/append/fadeIn` мне бы не пришлось ставить breakpoint. Там нечего высматривать, более того, в Chrome у меня jquery занесён в список и jquery код пропускается в «step into».

>3: Я всегда лишь полагаюсь на тесты, если я где-то ошибся с именем, то тест у меня тут же отвалится.

Конечно у цепочек есть свои недостатки, но так как у них «потоковая» логика, то читать и понимать код в разы проще.
Вот вы тут пишете
1. Строки файла должны быть максимально независимы.

Причина проста: если при изменении одной строки требуется изменение других, то это повышает риск конфликтов при слиянии веток.


Но при этом считаете правильным отсутствие точки с запятой в конце последней строки, хотя при добавлении строки это ведет к изменению двух строк, а не одной.

Не надо так.
Также тут можно заметить лишний семиколон (точку с запятой). Единственная причина его появления в этом месте — слепое следование правилам стайл-гайда, не понимая его принципов.
В многострочных правилах, это действительно необходимо, чтобы добавляемые в конец строки не приводили к изменению уже существующих.
Где здесь автор «считает правильным отсутствие точки с запятой»?
Да, действительно. Приношу автору извинения за невнимательность
    .icon {
        display: inline-block;
        width: 16px;
        height: 16px; // добавили семиколон
        background-image: url(/img/sprite.svg) // полезное изменение
    }

Вы серьезно используете такие комментарии в CSS?!
Печальное начало поучительной статьи
Ёпт, здесь просто иллюстрация к тому, какие строки будут показаны как изменённые при использовании vcs diff после добавления background-image. Т.е. автор показывает, что при полезном изменении всего одной строчки diff выдаст изменения в двух.
Поэтому позволительно писать с ошибками? Может ещё текст статьи писать на падонкаффском?
Я считаю это всё недопустимо, ибо статью читают и новички.
А если уметь читать, что понятно, что автор здесь приводит пример как не надо делать
Да только речь в статье не о комментариях в CSS. Так что BaNru прав.
К тому же далее в статье уже используется правильный формат комментариев.
Да, в статье речь о точках с запятой в последнем операторе. И автор пишет, что в однострочных конструкциях вроде
.icon--settings { background-position: -16px -16px }

точка с запятой не нужна, т.к. её дополнять не придётся, только изменять,
а вот в многострочных
.icon {
        display: inline-block;
        width: 16px;
        height: 16px;
        background-image: url(/img/sprite.svg);
    }

надо ставить точку с запятой в конце, чтобы при коммите не было бесполезного изменения с пунктуацией. И приводит пример этого самого корявого коммита.
Там не говорится, что «так комментарии писать нельзя».
Тут одна ошибка, там другая и вырастит новое поколение адептов попова.

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

При этом человек учит тут как правильно надо, но сам допускает ошибки. Заметь, именно синтаксису учит, в котором допустил наигрубейшую ошибку.
А кто сказал, что это CSS? Это Stylus.
Но в конце действительно есть пример с CSS и однострочными комментами. Я его поправлю, раз так сильно режет глаз.
Ненавижу статьи, в которым меня пытаются научить как «правильно» писать код. Все эти статьи однобоки и лишь выражают субъективный взгляд автора.

Например, я использую в работе большие мониторы (27"). Для меня вот эта методика разделения кода по строкам крайне не удобна. Получается длинный файл, который нужно долго прокручивать, чтобы что-то найти. Я использую запись кода в одну строку, кроме ветвления. Ветвление у меня организовано «лесенками». В итоге на большом мониторе видно большую часть кода, с которым можно легко работать.
Я это к чему… Это удобно лично мне, потому что у меня есть деньги на большой монитор. И поэтому я не пропагандирую свой способ и не пишу глупые статьи.
Коллеги помянут вас добрым словом, если им вдруг придется править ваш код на ноутбуке.
Ну, не надо этой истерии. Однострочный код преобразуется в многострочный (и обратно) путем 3 глобальных замен. Смех да и только…
Вам, случайно, никогда не доводилось мёржить код с длинными строками?
Человек работает один со своим кодом — его код, его правила. Вот когда начнёт работать в команде и один и тот же код будут редактировать разные люди тогда придётся поплакать со своими привычками.
Когда я купил побольше монитор я стал смотреть код в нескольких окнах сразу (Vim'овские окна), а не писать всё в одну строчку. У вас ведь не один файл в проекте? Так зачем городить длинные строчки, если можно вместо этого открыть рядышком, к примеру, шаблон, CSS и документацию? Такой вариант здорово разгружает мозги: то, что надо было помнить теперь можно просто посмотреть рядом. Но при этом такая разгрузка не ограничена одним файлом, как у вас.
Мне лично не нравиться переключать постоянно окна для поиска какого-либо куска кода. Мне проще пробежаться глазами по первым 3-4 символам в начале строки, чтобы найти то, что мне нужно.
Vim'овские окна! Вам не надо их переключать, все окна на одной вкладке всегда видны одновременно. А «по первым 3-4 символам» вы

— Не увидите код, находящийся в том же файле, но за несколько экранов. Если нужно с ним регулярно сверяться, то окна вам помогут, длинные строки — нет.
— То же самое, но для других файлов.
— Ну и в вашем коде документации нет, а в соседнем окне открыть её можно.

Поэтому лучше разделить экран на четыре окна, чем написать строку на весь экран. В IDE обычно тоже есть разные панельки с информацией (документация/отладчик/дерево классов/...) и на них тоже нужно место.
В статье нет конкретного стиля кодрования. Основная идея — всё должно быть обоснованно. Одним из обоснований является простота слияния веток (меньше изменений — меньше конфликтов).

Внимательно читай статью!
Кстати, тоже заметил это. Чем лучше разбираюсь в том что делаю, чем лучше «пишу программу» тем длиннее получаются строки.
Одна строка, одна сформулированная часть алгоритма.

Если потому нужно что-то исправить, то читая код сверху вниз сразу понятно кто за что отвечает и что где происходит.
А когда код полон переносов и другого сахара, делать это намного сложнее.
bingo!
Я понимаю, когда используют иностранные слова в тексте на русском языке если нет русского перевода, это упрощает понимание или русский аналог неточно отражает смысл, но «семиколон» — это уже перебор (мое оценочное суждение). Так можно и до «вордов, девайдов, экспрешенов, бранчингов и стейтментов» докатиться. Давайте уважать язык на котором говорим. Спасибо!
Причина проста: если при изменении одной строки требуется изменение других, то это повышает риск конфликтов при слиянии веток. Каждый конфликт — это дополнительное иногда значительное время на его разрешение.


Именно поэтому я пишу var перед каждой переменной:

var a = 1;
var b = 2;
var c = 3;


В этом случае добавление или удаление новой переменной и проще, и затрагивает только одну строку.
«Не сваливать все яйца (код) в одну корзину (файл/директорию).»

для хайлоада не очень здорово куча мелких файлов. на продакшне тогда лучше писать компилятор .js и .css в один файл.
По полученному классу «my-user__my-block-compact» сразу видно, что он склеен из двух кусков

это не то, о чем я написал.
Это, оказывается, в комментарии было — по крайней мере имеет представление о вопросе. Возможно, явно порекомендовать всё автоматически склеивать автор просто позабыл, сочтя очевидным (я всегда ожидаю от людей хорошее).
Попахивает какой-то анархией =)
Ставь пробелы где угодно, пихай лишние запятые в конец массива/хеша, забивай на точку с запятой в конце строки, пиши неграмотные имена…
Ещё и обоснование прикрутили — так проще) Извините, но НЕТ
Программист очень ленивый и сложный человек, (ну по крайне мере я) и я привык, что за меня все делает IDE и форматирование кода я возлагаю на ее стандарт или на какой то общий между теми IDE, что я работаю. Очень сложно настаивать и переносить форматирование под 100500 студий.
Когда уже будет одни общий стандарт конфигов? без лишних движений, сел и кодь.
Only those users with full accounts are able to leave comments. Log in, please.