Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 36
Холивар Табы vs Пробелы объявляется открытым! :D
Было бы интересно увидеть аргументы для табов и пробелов.
Аргументы в пользу табов:
— по ним удобнее перемещаться, чем по каждому пробелу, хотя в современных IDE для пробелов такое тоже поддерживается;
— фактически в любой IDE настраивается размер под себя (мне привычен 4), но при этом символ всего 1;
— если код не минифицируется, то он будет весить меньше, по сравнению с пробелами.
Если код встраивается в качестве примера (например, в блогах), то лучше было бы задать свойство tab-size.
Аргументы в пользу табов:
— по ним удобнее перемещаться, чем по каждому пробелу, хотя в современных IDE для пробелов такое тоже поддерживается;
— фактически в любой IDE настраивается размер под себя (мне привычен 4), но при этом символ всего 1;
— если код не минифицируется, то он будет весить меньше, по сравнению с пробелами.
Если код встраивается в качестве примера (например, в блогах), то лучше было бы задать свойство tab-size.
если код не минифицируется, то он будет весить меньше, по сравнению с пробелами.
O RLY?
У меня с приятелем был такой холивар как-то, закончилось тем, что он побежал в phpstorm менять \r\n на \n, тк ничего лучше аргумента о весе исходника он не нашел.
Единственный аргумент в пользу табов — размер отступов. Но на него есть отличный контр-аргумент — то что у Васи на 80 символов, у Пети — на 120.
Пробелы же дают возможность выравнивать код ровно так, как будет удобно его читать, и код будет читаться в любом редакторе одинаково. А норм редакторы, как вы выше заметили позволяют по пробелам перемещаться также легко, как по табам.
Сам использую очень давно пробелы, но время от времени вижу много исходников, где вместо таба (4 пробела) используется 2 а то и 1 пробел (github к примеру рекомендует в css использовать 2 пробела). Такой код очень сложно читать. А если бы использовались табы, то пользователь не заметил бы этого даже. А так приходится мучатся. И в итоге в проекте часть файлов использует 2 пробела, часть файлов 4, и часть 8 (встречал и такое часто).
Кто-то еще спорит об этом? Разве есть разница объективная между этими двумя подходами? Договорились один раз вначале (проголосовали, взяли готовый гайдлайн, лидер зафорсил) и все. Че тут разводить холиворы?
Ну вот пример. Я использую табы шириной 4 пробела, коллега — 2 пробела. В результате после моих правок отступы ему кажутся слишком большими (и тут он может в настройках саблайма поменять ширину таба на комфортные ему 2 пробела), а вот после его правок для меня всё слипшееся и его 2 пробела я никак на 4 не растяну. Приходится подстраиваться под коллегу. А юзали бы табы — каждый настроил любимую ширину и видел бы то, что хотел
Все эти «кажутся слишком большими» надуманны. В реальности разницы нету, дело привычки. Если бы табы были однозначно лучше пробелов, никто бы не спорил.
Ну и вы описываете ситуацию, когда на проекте один человек юзает табы, а другой пробелы. Это ИМХО нездорово, конечно. Надо уже как-то определиться с единым стилем отсупов и следовать ему. Другое дело, что какой это будет стиль — не важно.
Да понятно, что тут только вопрос договорённости и стиля кодирования. До чего договорились, то и используем.
Лично для себя закрыл этот вопрос в пользу табов.
Главное преимущество таба для отступов в том, что он семантичен: он предназначен для отступов, в отличие от пробела.
Думаю, большинство разумных людей раздражают абзацные отступы в Ворде, сделанные по нерадивости пробелами, а не абзацными отступами. А практически то же самое в своём коде, никого почему-то не раздражает :-)
Разумеется, если вы решили использовать табуляцию, то нужны именно смарт-табы.
Лично для себя закрыл этот вопрос в пользу табов.
Главное преимущество таба для отступов в том, что он семантичен: он предназначен для отступов, в отличие от пробела.
Думаю, большинство разумных людей раздражают абзацные отступы в Ворде, сделанные по нерадивости пробелами, а не абзацными отступами. А практически то же самое в своём коде, никого почему-то не раздражает :-)
Разумеется, если вы решили использовать табуляцию, то нужны именно смарт-табы.
Почти во всех примерах свойства элемента идут не в алфавитном порядке. Это не правильно. Куда удобнее искать нужное свойство по алфавиту.
Хотя я и сам пренебрегаю данным правилом, но для Style Guide это недопустимо.
Хотя я и сам пренебрегаю данным правилом, но для Style Guide это недопустимо.
Куда правильней сортировать и группировать по значению свойств
В алфавитном порядке с вендорскими префиксами будет не очень удобно.
Гораздно удобнее группировать по их назначению.
Гораздно удобнее группировать по их назначению.
Например, вот так
.declaration-order {
/* Позиционирование */
position: absolute;
z-index: 100;
top: 0;
right: 0;
left: 0;
bottom: 0;
/* Отступы */
margin-top: 20px;
margin-left: auto;
margin-right: auto;
padding: 8px 16px;
/* Блочная модель */
display: block;
float: left;
width: 100px;
height: 100px;
/* Типографика */
font-family: 'Helvetica Neue', sans-serif
font-size: 14px;
line-height: 24px;
text-align: center;
/* Оформление */
color: #333;
background-color: #f5f5f5;
border: 1px solid #e5e5e5;
border-radius: 3px;
opacity: 1;
/* Прочее */
transition: .25s ease-out;
transform: scale(.75);
}
Сколько времени у вас уйдет на поиск того или иного свойства?
А где находится text-decoration?
А background-position это Оформление или Позиционирование?
Ну а в целом я согласен и на такое, но и такого нет в статье.
Префиксы я отделяю и пишу либо в начале описания элемента, либо в конце.
Также их можно и в том месте, где безпрефиксная запись.
А где находится text-decoration?
А background-position это Оформление или Позиционирование?
Ну а в целом я согласен и на такое, но и такого нет в статье.
Префиксы я отделяю и пишу либо в начале описания элемента, либо в конце.
Также их можно и в том месте, где безпрефиксная запись.
Время на поиск свойства практически не затрачивается, если ты уже привык писать в таком порядке.
В том примере лишь малая часть свойств, все свойства описывать здесь нет смысла.
Большинство разработчиков, работая в командах, придерживаются их внутреннему стандарту, в котором задекларирован порядок этих свойств, и все пишут как один.
Кстати, для причесона порядка свойств можно использовать CSScomb, у него же есть и заготовки, которые можно использовать как есть или же подогнать под себя.
В том примере лишь малая часть свойств, все свойства описывать здесь нет смысла.
Большинство разработчиков, работая в командах, придерживаются их внутреннему стандарту, в котором задекларирован порядок этих свойств, и все пишут как один.
Кстати, для причесона порядка свойств можно использовать CSScomb, у него же есть и заготовки, которые можно использовать как есть или же подогнать под себя.
практически не затрачивается, если ты уже привык писать в таком порядке.А если не привык, то по алфавиту будет любому удобно искать, достаточно ему понять, что всё отсортировано в алфавитном порядке.
Кстати, для причесона порядка свойств можно использовать CSScomb, у него же есть и заготовкиДа-да-да, равно как и табов с пробелами, так и скобочек и многого другого.
нуу не скажите… я например за годы для себя выработал схему (очень удобно разбивать по логике блоки стилей):
.foo {
width
height
line-height
background
display
border
margin
padding
position
top, left, right, bottom
text-transform
text-decoration
color
font
...
}
Кто-то любит пробелы, а кто-то табы. Это из той же оперы.
Даже тут, сделанное мной замечание, которое казалось бы является нормой — вызывает холивар.
Я думал Style Guide пишутся чтобы избежать холиваров и прийти к единому мнению.
Но видимо это особенный случай.
Процитирую статью
На данный момент Вы и пару комментаторов выше привели самый весомый аргумент «я (мне) так удобнее», что и не поспоришь.
Давайте так поступим. Я предлагаю вам двоим (с GC92) сначала прийти к единому мнению (какие блоки будут, что к чему относится), а потом продолжим разговор.
PS А на каком этапе надо применять блочный вариант? Вот так вот выглядит глупо и не удобно читать будет простыню из подобного
А если добавить сюда ещё и комментарии, как в примере GC92…
Даже тут, сделанное мной замечание, которое казалось бы является нормой — вызывает холивар.
Я думал Style Guide пишутся чтобы избежать холиваров и прийти к единому мнению.
Но видимо это особенный случай.
Процитирую статью
Руководства по оформлению кода должны осваиваться и применяться всеми разработчиками, а любые отклонения от правил должны быть обоснованы.
На данный момент Вы и пару комментаторов выше привели самый весомый аргумент «я (мне) так удобнее», что и не поспоришь.
Давайте так поступим. Я предлагаю вам двоим (с GC92) сначала прийти к единому мнению (какие блоки будут, что к чему относится), а потом продолжим разговор.
PS А на каком этапе надо применять блочный вариант? Вот так вот выглядит глупо и не удобно читать будет простыню из подобного
.foo {
width
border
font
}А если добавить сюда ещё и комментарии, как в примере GC92…
Не заметил сначала его «простыни») ну там все логично и понятно, а вы предлагаете стили писать в строчку (для сохранности места)? =/
ЗЫ я против всяких холиваров, просто среагрировал на ваше:
ЗЗЫ я всегда за импрувинг скиллов) так что если кто-то предложит какой-то интересный вариант, почему бы не использовать его…
ЗЗЗЫ к таким дичайшим гайдлайнам как в статье я всегда скептически относился — местами там жуткие примеры
ЗЫ я против всяких холиваров, просто среагрировал на ваше:
Куда удобнее искать нужное свойство по алфавиту.
ЗЗЫ я всегда за импрувинг скиллов) так что если кто-то предложит какой-то интересный вариант, почему бы не использовать его…
ЗЗЗЫ к таким дичайшим гайдлайнам как в статье я всегда скептически относился — местами там жуткие примеры
Не заметил сначала его «простыни») ну там все логично и понятно, а вы предлагаете стили писать в строчку (для сохранности места)? =/Зачем так сильно передергивать? Вы предложили разбивать на блоки и разбивать отбивками (пустыми строками). А если там всего два-три свойства из разных блоков? Я предлагаю без отбивок и в алфавитном порядке (сам я лично отбиваю только вендорные свойства, делаю блоком). И даже если человек работал всегда с блоками, то ему надо будет 10 секунд (ну может побольше, если процессор слабенький (я про мозг если что)) на то, чтобы понять, перестроится, адаптироваться. А учитывая что многие препроцессоры, файрбаги и IDE именно так строят код… именно поэтому я и сказал, что это должно быть нормой и должно упоминаться в Style Guide.
.foo {
border
font
width
}В данном случае, даже если случайно перепутать алфавитный порядок (соседние буквы например) — всё равно будет легко найти. А вот если перепутать блоки, то придется просматривать все блоки. А отбивки ещё могут заставить скроллить.
Отдельный разработчик, если ему угодно, может и на блоки разбить и делать всё «назло» Style Guide. Но статья то не про «мне так удобно, мне так нравится».
Я например, ради эксперимента, как-то пробовал писать колонками:
Скрин, код не форматируется тут нормально
Это замечательное извращение и кому-то может понравится (мне не понравилось).
Особенно если разбить на колонки по блокам. У кого широкоформатный монитор и пару сотен символов умещается — это вообще красота будет — колонка позиционирования, колонка типографики и т.д. Ведь удобно, когда знаешь заранее в какой колонке искать. :D
Таблица содержимого
Зачем? Современные IDE имеют отличный поиск, переход к селектору прямо из html, плагины позволяют прямо из браузера это делать.
Именование секций кода
Секции — в отдельные файлы.
.foo {
-webkit-border-radius: 3px;
-moz-border-radius: 3px;
border-radius: 3px;
}Такое вообще выкинуть из своего кода вместе с миксинами для префиксов, подрубить autoprefixer и перестать об этом задумываться.
Вы видимо не очень внимательно читали статью. В ней сказано, что таблица содержимого предназначена не для поиска каких-то кусков кода, а для того, чтобы разработчик мог ознакомиться со структурой файла / файлов и с предназначением отдельных разделов.
По поводу именования секций, в статье, опять же, сказано, что не всегда имеется возможность разбивать код на файлы. А если и есть такая возможность, то все равно название секции желательно добавить в начале файла.
По поводу префиксов согласен, стоит использовать автопрефиксер, но этот кусок кода был дан для того, чтобы показать, как можно расставлять отступы.
По поводу именования секций, в статье, опять же, сказано, что не всегда имеется возможность разбивать код на файлы. А если и есть такая возможность, то все равно название секции желательно добавить в начале файла.
По поводу префиксов согласен, стоит использовать автопрефиксер, но этот кусок кода был дан для того, чтобы показать, как можно расставлять отступы.
Скажите, вы из тех людей, кто для конструктора в классе пишет комментарий «Constructor.»?
Если секция называется «ANOTHER-SECTION», почему бы файл не назвать another-section.css и не городить капитанства?
Ровно как и структура файлов — она очевидна как только ее видишь, если код разбит на, как вы называете, секции. github.com/twbs/bootstrap/tree/master/less — над проектом почти 600 контрибьюторов трудились, никакого оглавления там нет.
А можно конкретные причины невозможности использовать разбиение на файлы? Я представляю себе только демку в jsfiddle, или аналогах.
По поводу префиксов — по моему вообще надо о них забыть и не использовать ни в каких примерах.
Если секция называется «ANOTHER-SECTION», почему бы файл не назвать another-section.css и не городить капитанства?
Ровно как и структура файлов — она очевидна как только ее видишь, если код разбит на, как вы называете, секции. github.com/twbs/bootstrap/tree/master/less — над проектом почти 600 контрибьюторов трудились, никакого оглавления там нет.
А можно конкретные причины невозможности использовать разбиение на файлы? Я представляю себе только демку в jsfiddle, или аналогах.
По поводу префиксов — по моему вообще надо о них забыть и не использовать ни в каких примерах.
Может уже все гайды как то систематизировать и пронумеровать, чтобы не было бесполезных войн тупоконечников с остроконечниками?
Пишу в один ряд
Спасибо за статью.
По-моему, некоторые правила плохие. Например, отступы в «логически связанных» свойствах или выравнивание цифр, лошадиные комментарии и, конечно, оглавление.
По мне так, комментарии в css нужны только в ОЧЕНЬ специфических местах, где не очевидно что вообще происходит. CSS же декларативный. А то начинается
width: 200px /* это высота */
... /* это стул на нем сидят; это стол, за ним едят */
Ну, иногда всё же они бывают полезными. Блок можно подписать.
Не всегда на больших проектах получается придумывать разнообразные хорошие названия.
Иногда, скажем, в коммент можно запихнуть zen-coding-разметку
Не всегда на больших проектах получается придумывать разнообразные хорошие названия.
Иногда, скажем, в коммент можно запихнуть zen-coding-разметку
В следующей части как раз сказано о том, что не стоит комментировать очевидные вещи, и в целом рассказано о том, что и как комментировать.
Про БЭМ он знает: cssguidelin.es/#bem-like-naming
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CSS GuideLines, часть 1. Синтаксис и форматирование