Comments 64
Семиколоны?
UFO just landed and posted this here
внутрь семиколоны
Точки с запятой не нужны в 99.99% случаев.
Обычно, если вы склеиваете файлы и в вашем файле код начинается с открытой скобки — это единственное место, где точка с запятой необходима «на всякий случай». И всё. Все остальные места необходимости точки с запятой очевидны для вашего кода (которые, как правило, отсутствуют вовсе).
Ставить их всегда — это как ходить под зонтом в пределах крыши — а вдруг что-то на голову свалится.
Обычно, если вы склеиваете файлы и в вашем файле код начинается с открытой скобки — это единственное место, где точка с запятой необходима «на всякий случай». И всё. Все остальные места необходимости точки с запятой очевидны для вашего кода (которые, как правило, отсутствуют вовсе).
Ставить их всегда — это как ходить под зонтом в пределах крыши — а вдруг что-то на голову свалится.
UFO just landed and posted this here
Вы правы, если минификатор сам будет расставлять точки с запятой, а если не будет? Лучше «ходить с зонтом под крышей».
Мне свалилось. Как-то из-за пропущенной точки с запятой образовалась труднонаходимая ошибка.
Если понимать, где их ставить необходимо, где целесообразно «на всякий случай» (исключительно для защиты от кода файлов, которые вы не пишете, если они склеиваются), а где не нужно вовсе — ничего не свалится.
Касательно стайлгайдов, где рекомендуется ставить везде — новичкам сложно понять где их нужно ставить сходу, и предостережение перерастает в базовый стиль кодирования.
Касательно стайлгайдов, где рекомендуется ставить везде — новичкам сложно понять где их нужно ставить сходу, и предостережение перерастает в базовый стиль кодирования.
UFO just landed and posted this here
Ок, вместо дополнения просто оставлю это здесь: www.quizful.net/post/semicolons-in-javascript-are-optional-mmarohnic
Да, там где-то внизу есть список:
Про очевидные места в вашем коде (не в начале файла) имелись в виду скобки (в том числе и квадратные) и, преимущественно,
Да, там где-то внизу есть список:
(, [, +, -, /, но если ваш файл первой строчкой начинается с чего-то, кроме открывающей круглой скобки — это, по меньшей мере, странно, и про стиль кодирования тут говорить уже глупо.Про очевидные места в вашем коде (не в начале файла) имелись в виду скобки (в том числе и квадратные) и, преимущественно,
+, может быть ещё и -, как правило в строках --i, ++i.UFO just landed and posted this here
Вот ещё в догонку: habrahabr.ru/post/111563/
Там неплохо разложены по полочкам все заблуждения и опасные места. В том числе break, continue, return — но это, как по мне, уже проблемы стиля кодирования, где такое допускается.
Конечно, можно писать точки с запятыми везде, где нужно и не нужно, и это, может быть, убережёт вас от лишних проблем. Но это не является необходимостью, правилом или ещё чем-либо таким магическим и единственно-верным. По моему, если в вашем коде есть места, где без точек с запятыми поведение программы непредсказуемо — то проблема в другом.
Там неплохо разложены по полочкам все заблуждения и опасные места. В том числе break, continue, return — но это, как по мне, уже проблемы стиля кодирования, где такое допускается.
Конечно, можно писать точки с запятыми везде, где нужно и не нужно, и это, может быть, убережёт вас от лишних проблем. Но это не является необходимостью, правилом или ещё чем-либо таким магическим и единственно-верным. По моему, если в вашем коде есть места, где без точек с запятыми поведение программы непредсказуемо — то проблема в другом.
Сюда ещё хотелось бы добавить фигурные скобки и «ставьте их везде во избежание проблем с отступами». Мне нравится coffeescript отсутствием скобок и обязательством ставить отступы. Он как бы обязывает обращать много внимания на важность отступов, и, если бы столько внимания было уделено отступам в js, то никогда не возникло бы проблем с фигурными скобками в однострочных конструкциях условий и циклов.
То есть, проще говоря, проблема не там, где кажется.
То есть, проще говоря, проблема не там, где кажется.
Ну и да, ещё после
i++,i--, но прежде всего стоит подумать, зачем оно такое в коде, если оно лежит вне условия for, где точки с запятыми обязательны. А если оно у вас необходимо, я уверен, что вы вполне понимаете где и зачем ставить точки с запятыми.Это лишняя вещь для запоминания.
Отличный аргумент, беру на вооружение!
Если у вас возникают проблемы при склейке или минификации файлов из-за забытого семиколона, значит вы используете кривой инструмент написанный человеком, плохо разбирающемся в семантике языка, который он взялся преобразовывать. Использование кривых инструментов — основной источник ваших проблем, а не раздолбайство программистов.
Для новичков же есть более полезное правило, чем «ставьте везде семиколоны». Звучит оно так: Если строка не является продолжением предыдущей, то начинайте её с ключевого слова или имени объекта
Проиллюстрирую примером, проблемного для глупого склейщика кода:
Глупый склейщик соберёт что-то такое:
И это не будет работать. Более толковый склейщик сгенерирует нечто вроде:
Но если придерживаться предложенного мной правила, то даже глупый склейщик ничего не сломает:
К сожалению, многие писатели мануалов, учебников и стайл-гайдов не в курсе существования оператора void.
Если у вас возникают проблемы при склейке или минификации файлов из-за забытого семиколона, значит вы используете кривой инструмент написанный человеком, плохо разбирающемся в семантике языка, который он взялся преобразовывать. Использование кривых инструментов — основной источник ваших проблем, а не раздолбайство программистов.
Для новичков же есть более полезное правило, чем «ставьте везде семиколоны». Звучит оно так: Если строка не является продолжением предыдущей, то начинайте её с ключевого слова или имени объекта
Проиллюстрирую примером, проблемного для глупого склейщика кода:
(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.
Ещё можно себе руку сломать, чтобы спину удобнее чесать было.
> К сожалению, многие писатели мануалов, учебников и стайл-гайдов…
Не учебников, а туториалов!
Райтеры туториалов не в курсе экзистенции…
Не учебников, а туториалов!
Райтеры туториалов не в курсе экзистенции…
Пример с 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/)
1.1. Из-за отсутствия переменных вы не можете посмотреть в дебаггере где какое состояние.
1.2. Вы не сможете поставить точку остановка на середину строки, а при исполнении «по шагам» не будете видеть в каком месте сейчас находится интерпретатор.
2. При усложнении логики у вас получится лапша в одну строку.
3. Можете забыть про автодополнение в IDE и сттатические варнинги при вызове несуществующего метода.
4. Некоторые виды логики нельзя выразить в виде экспрешенов. Например, когда в одном случае нужно два метода вызвать, а в другом один. Или с разным числом и типами параметров. Или в цикле. Или когда нужно временно сменить контекст (я в курсе про костыль в jQuery api.jquery.com/end/)
//cc garex
Смысловой контекст — вот что имеет значение. Для простого выражения из примера делать отдельный метод нет смысла. Поэтому я сказал, что пример не корректный… Если будем говорить о других более сложных примерах, то
>1: Цепочки разумеется сложнее в отладке, но опять же из примера на `clone/text/append/fadeIn` мне бы не пришлось ставить breakpoint. Там нечего высматривать, более того, в Chrome у меня jquery занесён в список и jquery код пропускается в «step into».
>3: Я всегда лишь полагаюсь на тесты, если я где-то ошибся с именем, то тест у меня тут же отвалится.
Конечно у цепочек есть свои недостатки, но так как у них «потоковая» логика, то читать и понимать код в разы проще.
Смысловой контекст — вот что имеет значение. Для простого выражения из примера делать отдельный метод нет смысла. Поэтому я сказал, что пример не корректный… Если будем говорить о других более сложных примерах, то
`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 и однострочными комментами. Я его поправлю, раз так сильно режет глаз.
Но в конце действительно есть пример с CSS и однострочными комментами. Я его поправлю, раз так сильно режет глаз.
Сколько людей, столько и стилей :)
Ненавижу статьи, в которым меня пытаются научить как «правильно» писать код. Все эти статьи однобоки и лишь выражают субъективный взгляд автора.
Например, я использую в работе большие мониторы (27"). Для меня вот эта методика разделения кода по строкам крайне не удобна. Получается длинный файл, который нужно долго прокручивать, чтобы что-то найти. Я использую запись кода в одну строку, кроме ветвления. Ветвление у меня организовано «лесенками». В итоге на большом мониторе видно большую часть кода, с которым можно легко работать.
Я это к чему… Это удобно лично мне, потому что у меня есть деньги на большой монитор. И поэтому я не пропагандирую свой способ и не пишу глупые статьи.
Например, я использую в работе большие мониторы (27"). Для меня вот эта методика разделения кода по строкам крайне не удобна. Получается длинный файл, который нужно долго прокручивать, чтобы что-то найти. Я использую запись кода в одну строку, кроме ветвления. Ветвление у меня организовано «лесенками». В итоге на большом мониторе видно большую часть кода, с которым можно легко работать.
Я это к чему… Это удобно лично мне, потому что у меня есть деньги на большой монитор. И поэтому я не пропагандирую свой способ и не пишу глупые статьи.
Коллеги помянут вас добрым словом, если им вдруг придется править ваш код на ноутбуке.
Вам, случайно, никогда не доводилось мёржить код с длинными строками?
Когда я купил побольше монитор я стал смотреть код в нескольких окнах сразу (Vim'овские окна), а не писать всё в одну строчку. У вас ведь не один файл в проекте? Так зачем городить длинные строчки, если можно вместо этого открыть рядышком, к примеру, шаблон, CSS и документацию? Такой вариант здорово разгружает мозги: то, что надо было помнить теперь можно просто посмотреть рядом. Но при этом такая разгрузка не ограничена одним файлом, как у вас.
Мне лично не нравиться переключать постоянно окна для поиска какого-либо куска кода. Мне проще пробежаться глазами по первым 3-4 символам в начале строки, чтобы найти то, что мне нужно.
Vim'овские окна! Вам не надо их переключать, все окна на одной вкладке всегда видны одновременно. А «по первым 3-4 символам» вы
— Не увидите код, находящийся в том же файле, но за несколько экранов. Если нужно с ним регулярно сверяться, то окна вам помогут, длинные строки — нет.
— То же самое, но для других файлов.
— Ну и в вашем коде документации нет, а в соседнем окне открыть её можно.
Поэтому лучше разделить экран на четыре окна, чем написать строку на весь экран. В IDE обычно тоже есть разные панельки с информацией (документация/отладчик/дерево классов/...) и на них тоже нужно место.
— Не увидите код, находящийся в том же файле, но за несколько экранов. Если нужно с ним регулярно сверяться, то окна вам помогут, длинные строки — нет.
— То же самое, но для других файлов.
— Ну и в вашем коде документации нет, а в соседнем окне открыть её можно.
Поэтому лучше разделить экран на четыре окна, чем написать строку на весь экран. В IDE обычно тоже есть разные панельки с информацией (документация/отладчик/дерево классов/...) и на них тоже нужно место.
В статье нет конкретного стиля кодрования. Основная идея — всё должно быть обоснованно. Одним из обоснований является простота слияния веток (меньше изменений — меньше конфликтов).
Внимательно читай статью!
Внимательно читай статью!
Кстати, тоже заметил это. Чем лучше разбираюсь в том что делаю, чем лучше «пишу программу» тем длиннее получаются строки.
Одна строка, одна сформулированная часть алгоритма.
Если потому нужно что-то исправить, то читая код сверху вниз сразу понятно кто за что отвечает и что где происходит.
А когда код полон переносов и другого сахара, делать это намного сложнее.
Одна строка, одна сформулированная часть алгоритма.
Если потому нужно что-то исправить, то читая код сверху вниз сразу понятно кто за что отвечает и что где происходит.
А когда код полон переносов и другого сахара, делать это намного сложнее.
bingo!
Я понимаю, когда используют иностранные слова в тексте на русском языке если нет русского перевода, это упрощает понимание или русский аналог неточно отражает смысл, но «семиколон» — это уже перебор (мое оценочное суждение). Так можно и до «вордов, девайдов, экспрешенов, бранчингов и стейтментов» докатиться. Давайте уважать язык на котором говорим. Спасибо!
Я понимаю, когда используют иностранные слова в тексте на русском языке если нет русского перевода, это упрощает понимание или русский аналог неточно отражает смысл, но «семиколон» — это уже перебор (мое оценочное суждение). Так можно и до «вордов, девайдов, экспрешенов, бранчингов и стейтментов» докатиться. Давайте уважать язык на котором говорим. Спасибо!
Причина проста: если при изменении одной строки требуется изменение других, то это повышает риск конфликтов при слиянии веток. Каждый конфликт — это дополнительное иногда значительное время на его разрешение.
Именно поэтому я пишу
var перед каждой переменной:var a = 1;
var b = 2;
var c = 3;
В этом случае добавление или удаление новой переменной и проще, и затрагивает только одну строку.
«Не сваливать все яйца (код) в одну корзину (файл/директорию).»
для хайлоада не очень здорово куча мелких файлов. на продакшне тогда лучше писать компилятор .js и .css в один файл.
для хайлоада не очень здорово куча мелких файлов. на продакшне тогда лучше писать компилятор .js и .css в один файл.
Тут речь о разработке, а не о продакшене.
Автор про склеивание упоминает ведь.
По полученному классу «my-user__my-block-compact» сразу видно, что он склеен из двух кусков
это не то, о чем я написал.
Это, оказывается, в комментарии было — по крайней мере имеет представление о вопросе. Возможно, явно порекомендовать всё автоматически склеивать автор просто позабыл, сочтя очевидным (я всегда ожидаю от людей хорошее).
Попахивает какой-то анархией =)
Ставь пробелы где угодно, пихай лишние запятые в конец массива/хеша, забивай на точку с запятой в конце строки, пиши неграмотные имена…
Ещё и обоснование прикрутили — так проще) Извините, но НЕТ
Ставь пробелы где угодно, пихай лишние запятые в конец массива/хеша, забивай на точку с запятой в конце строки, пиши неграмотные имена…
Ещё и обоснование прикрутили — так проще) Извините, но НЕТ
Программист очень ленивый и сложный человек, (ну по крайне мере я) и я привык, что за меня все делает IDE и форматирование кода я возлагаю на ее стандарт или на какой то общий между теми IDE, что я работаю. Очень сложно настаивать и переносить форматирование под 100500 студий.
Когда уже будет одни общий стандарт конфигов? без лишних движений, сел и кодь.
Когда уже будет одни общий стандарт конфигов? без лишних движений, сел и кодь.
Есть editorconfig. Но он описывает далеко не всё.
Sign up to leave a comment.
Принципы написания кода