Комментарии 36
Холивар Табы vs Пробелы объявляется открытым! :D
+15
Было бы интересно увидеть аргументы для табов и пробелов.
Аргументы в пользу табов:
— по ним удобнее перемещаться, чем по каждому пробелу, хотя в современных IDE для пробелов такое тоже поддерживается;
— фактически в любой IDE настраивается размер под себя (мне привычен 4), но при этом символ всего 1;
— если код не минифицируется, то он будет весить меньше, по сравнению с пробелами.
Если код встраивается в качестве примера (например, в блогах), то лучше было бы задать свойство tab-size.
Аргументы в пользу табов:
— по ним удобнее перемещаться, чем по каждому пробелу, хотя в современных IDE для пробелов такое тоже поддерживается;
— фактически в любой IDE настраивается размер под себя (мне привычен 4), но при этом символ всего 1;
— если код не минифицируется, то он будет весить меньше, по сравнению с пробелами.
Если код встраивается в качестве примера (например, в блогах), то лучше было бы задать свойство tab-size.
+2
если код не минифицируется, то он будет весить меньше, по сравнению с пробелами.
O RLY?
У меня с приятелем был такой холивар как-то, закончилось тем, что он побежал в phpstorm менять \r\n на \n, тк ничего лучше аргумента о весе исходника он не нашел.
Единственный аргумент в пользу табов — размер отступов. Но на него есть отличный контр-аргумент — то что у Васи на 80 символов, у Пети — на 120.
Пробелы же дают возможность выравнивать код ровно так, как будет удобно его читать, и код будет читаться в любом редакторе одинаково. А норм редакторы, как вы выше заметили позволяют по пробелам перемещаться также легко, как по табам.
-2
Сам использую очень давно пробелы, но время от времени вижу много исходников, где вместо таба (4 пробела) используется 2 а то и 1 пробел (github к примеру рекомендует в css использовать 2 пробела). Такой код очень сложно читать. А если бы использовались табы, то пользователь не заметил бы этого даже. А так приходится мучатся. И в итоге в проекте часть файлов использует 2 пробела, часть файлов 4, и часть 8 (встречал и такое часто).
0
Кто-то еще спорит об этом? Разве есть разница объективная между этими двумя подходами? Договорились один раз вначале (проголосовали, взяли готовый гайдлайн, лидер зафорсил) и все. Че тут разводить холиворы?
+2
Ну вот пример. Я использую табы шириной 4 пробела, коллега — 2 пробела. В результате после моих правок отступы ему кажутся слишком большими (и тут он может в настройках саблайма поменять ширину таба на комфортные ему 2 пробела), а вот после его правок для меня всё слипшееся и его 2 пробела я никак на 4 не растяну. Приходится подстраиваться под коллегу. А юзали бы табы — каждый настроил любимую ширину и видел бы то, что хотел
+1
Все эти «кажутся слишком большими» надуманны. В реальности разницы нету, дело привычки. Если бы табы были однозначно лучше пробелов, никто бы не спорил.
0
Ну и вы описываете ситуацию, когда на проекте один человек юзает табы, а другой пробелы. Это ИМХО нездорово, конечно. Надо уже как-то определиться с единым стилем отсупов и следовать ему. Другое дело, что какой это будет стиль — не важно.
0
Можно абстрагироваться от данного примера: ситуация когда все используют табы разной ширины в пробелах комфортнее (ввиду настраиваемости этой ширины в современных редакторах), чем ситуация, когда все используют отступ с разным количеством пробелов.
0
Да понятно, что тут только вопрос договорённости и стиля кодирования. До чего договорились, то и используем.
Лично для себя закрыл этот вопрос в пользу табов.
Главное преимущество таба для отступов в том, что он семантичен: он предназначен для отступов, в отличие от пробела.
Думаю, большинство разумных людей раздражают абзацные отступы в Ворде, сделанные по нерадивости пробелами, а не абзацными отступами. А практически то же самое в своём коде, никого почему-то не раздражает :-)
Разумеется, если вы решили использовать табуляцию, то нужны именно смарт-табы.
Лично для себя закрыл этот вопрос в пользу табов.
Главное преимущество таба для отступов в том, что он семантичен: он предназначен для отступов, в отличие от пробела.
Думаю, большинство разумных людей раздражают абзацные отступы в Ворде, сделанные по нерадивости пробелами, а не абзацными отступами. А практически то же самое в своём коде, никого почему-то не раздражает :-)
Разумеется, если вы решили использовать табуляцию, то нужны именно смарт-табы.
+7
Почти во всех примерах свойства элемента идут не в алфавитном порядке. Это не правильно. Куда удобнее искать нужное свойство по алфавиту.
Хотя я и сам пренебрегаю данным правилом, но для Style Guide это недопустимо.
Хотя я и сам пренебрегаю данным правилом, но для Style Guide это недопустимо.
0
Куда правильней сортировать и группировать по значению свойств
+2
В алфавитном порядке с вендорскими префиксами будет не очень удобно.
Гораздно удобнее группировать по их назначению.
Гораздно удобнее группировать по их назначению.
Например, вот так
.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);
}
+1
Сколько времени у вас уйдет на поиск того или иного свойства?
А где находится text-decoration?
А background-position это Оформление или Позиционирование?
Ну а в целом я согласен и на такое, но и такого нет в статье.
Префиксы я отделяю и пишу либо в начале описания элемента, либо в конце.
Также их можно и в том месте, где безпрефиксная запись.
А где находится text-decoration?
А background-position это Оформление или Позиционирование?
Ну а в целом я согласен и на такое, но и такого нет в статье.
Префиксы я отделяю и пишу либо в начале описания элемента, либо в конце.
Также их можно и в том месте, где безпрефиксная запись.
0
Время на поиск свойства практически не затрачивается, если ты уже привык писать в таком порядке.
В том примере лишь малая часть свойств, все свойства описывать здесь нет смысла.
Большинство разработчиков, работая в командах, придерживаются их внутреннему стандарту, в котором задекларирован порядок этих свойств, и все пишут как один.
Кстати, для причесона порядка свойств можно использовать CSScomb, у него же есть и заготовки, которые можно использовать как есть или же подогнать под себя.
В том примере лишь малая часть свойств, все свойства описывать здесь нет смысла.
Большинство разработчиков, работая в командах, придерживаются их внутреннему стандарту, в котором задекларирован порядок этих свойств, и все пишут как один.
Кстати, для причесона порядка свойств можно использовать CSScomb, у него же есть и заготовки, которые можно использовать как есть или же подогнать под себя.
0
практически не затрачивается, если ты уже привык писать в таком порядке.А если не привык, то по алфавиту будет любому удобно искать, достаточно ему понять, что всё отсортировано в алфавитном порядке.
Кстати, для причесона порядка свойств можно использовать CSScomb, у него же есть и заготовкиДа-да-да, равно как и табов с пробелами, так и скобочек и многого другого.
0
нуу не скажите… я например за годы для себя выработал схему (очень удобно разбивать по логике блоки стилей):
.foo {
width
height
line-height
background
display
border
margin
padding
position
top, left, right, bottom
text-transform
text-decoration
color
font
...
}
0
Кто-то любит пробелы, а кто-то табы. Это из той же оперы.
Даже тут, сделанное мной замечание, которое казалось бы является нормой — вызывает холивар.
Я думал Style Guide пишутся чтобы избежать холиваров и прийти к единому мнению.
Но видимо это особенный случай.
Процитирую статью
На данный момент Вы и пару комментаторов выше привели самый весомый аргумент «я (мне) так удобнее», что и не поспоришь.
Давайте так поступим. Я предлагаю вам двоим (с GC92) сначала прийти к единому мнению (какие блоки будут, что к чему относится), а потом продолжим разговор.
PS А на каком этапе надо применять блочный вариант? Вот так вот выглядит глупо и не удобно читать будет простыню из подобного
А если добавить сюда ещё и комментарии, как в примере GC92…
Даже тут, сделанное мной замечание, которое казалось бы является нормой — вызывает холивар.
Я думал Style Guide пишутся чтобы избежать холиваров и прийти к единому мнению.
Но видимо это особенный случай.
Процитирую статью
Руководства по оформлению кода должны осваиваться и применяться всеми разработчиками, а любые отклонения от правил должны быть обоснованы.
На данный момент Вы и пару комментаторов выше привели самый весомый аргумент «я (мне) так удобнее», что и не поспоришь.
Давайте так поступим. Я предлагаю вам двоим (с GC92) сначала прийти к единому мнению (какие блоки будут, что к чему относится), а потом продолжим разговор.
PS А на каком этапе надо применять блочный вариант? Вот так вот выглядит глупо и не удобно читать будет простыню из подобного
.foo {
width
border
font
}
А если добавить сюда ещё и комментарии, как в примере GC92…
0
Не заметил сначала его «простыни») ну там все логично и понятно, а вы предлагаете стили писать в строчку (для сохранности места)? =/
ЗЫ я против всяких холиваров, просто среагрировал на ваше:
ЗЗЫ я всегда за импрувинг скиллов) так что если кто-то предложит какой-то интересный вариант, почему бы не использовать его…
ЗЗЗЫ к таким дичайшим гайдлайнам как в статье я всегда скептически относился — местами там жуткие примеры
ЗЫ я против всяких холиваров, просто среагрировал на ваше:
Куда удобнее искать нужное свойство по алфавиту.
ЗЗЫ я всегда за импрувинг скиллов) так что если кто-то предложит какой-то интересный вариант, почему бы не использовать его…
ЗЗЗЫ к таким дичайшим гайдлайнам как в статье я всегда скептически относился — местами там жуткие примеры
0
Не заметил сначала его «простыни») ну там все логично и понятно, а вы предлагаете стили писать в строчку (для сохранности места)? =/Зачем так сильно передергивать? Вы предложили разбивать на блоки и разбивать отбивками (пустыми строками). А если там всего два-три свойства из разных блоков? Я предлагаю без отбивок и в алфавитном порядке (сам я лично отбиваю только вендорные свойства, делаю блоком). И даже если человек работал всегда с блоками, то ему надо будет 10 секунд (ну может побольше, если процессор слабенький (я про мозг если что)) на то, чтобы понять, перестроится, адаптироваться. А учитывая что многие препроцессоры, файрбаги и IDE именно так строят код… именно поэтому я и сказал, что это должно быть нормой и должно упоминаться в Style Guide.
.foo {
border
font
width
}
В данном случае, даже если случайно перепутать алфавитный порядок (соседние буквы например) — всё равно будет легко найти. А вот если перепутать блоки, то придется просматривать все блоки. А отбивки ещё могут заставить скроллить.
Отдельный разработчик, если ему угодно, может и на блоки разбить и делать всё «назло» Style Guide. Но статья то не про «мне так удобно, мне так нравится».
Я например, ради эксперимента, как-то пробовал писать колонками:
Скрин, код не форматируется тут нормально
Это замечательное извращение и кому-то может понравится (мне не понравилось).
Особенно если разбить на колонки по блокам. У кого широкоформатный монитор и пару сотен символов умещается — это вообще красота будет — колонка позиционирования, колонка типографики и т.д. Ведь удобно, когда знаешь заранее в какой колонке искать. :D
0
Таблица содержимого
Зачем? Современные IDE имеют отличный поиск, переход к селектору прямо из html, плагины позволяют прямо из браузера это делать.
Именование секций кода
Секции — в отдельные файлы.
.foo {
-webkit-border-radius: 3px;
-moz-border-radius: 3px;
border-radius: 3px;
}
Такое вообще выкинуть из своего кода вместе с миксинами для префиксов, подрубить autoprefixer и перестать об этом задумываться.
+1
Вы видимо не очень внимательно читали статью. В ней сказано, что таблица содержимого предназначена не для поиска каких-то кусков кода, а для того, чтобы разработчик мог ознакомиться со структурой файла / файлов и с предназначением отдельных разделов.
По поводу именования секций, в статье, опять же, сказано, что не всегда имеется возможность разбивать код на файлы. А если и есть такая возможность, то все равно название секции желательно добавить в начале файла.
По поводу префиксов согласен, стоит использовать автопрефиксер, но этот кусок кода был дан для того, чтобы показать, как можно расставлять отступы.
По поводу именования секций, в статье, опять же, сказано, что не всегда имеется возможность разбивать код на файлы. А если и есть такая возможность, то все равно название секции желательно добавить в начале файла.
По поводу префиксов согласен, стоит использовать автопрефиксер, но этот кусок кода был дан для того, чтобы показать, как можно расставлять отступы.
+1
Скажите, вы из тех людей, кто для конструктора в классе пишет комментарий «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, или аналогах.
По поводу префиксов — по моему вообще надо о них забыть и не использовать ни в каких примерах.
+2
НЛО прилетело и опубликовало эту надпись здесь
Может уже все гайды как то систематизировать и пронумеровать, чтобы не было бесполезных войн тупоконечников с остроконечниками?
0
Удивлен, что проблема еще существует. У меня пока глаза на месте и я могу читать любой css от любого извращенца и мне все будет понятно. Зачем создавать человеку правила? Пускай пишет как ему угодно. А если вы сами очень чувствительны в восприятии чужого кода, то для этого есть множество инструментов, которые перебьют табы на пробелы и обратно, отсортируют все хоть в алфавитном порядке наоборот и вообще как угодно.
+2
Пишу в один ряд
0
Спасибо за статью.
0
По-моему, некоторые правила плохие. Например, отступы в «логически связанных» свойствах или выравнивание цифр, лошадиные комментарии и, конечно, оглавление.
+1
По мне так, комментарии в css нужны только в ОЧЕНЬ специфических местах, где не очевидно что вообще происходит. CSS же декларативный. А то начинается
width: 200px /* это высота */
... /* это стул на нем сидят; это стол, за ним едят */
0
Ну, иногда всё же они бывают полезными. Блок можно подписать.
Не всегда на больших проектах получается придумывать разнообразные хорошие названия.
Иногда, скажем, в коммент можно запихнуть zen-coding-разметку
Не всегда на больших проектах получается придумывать разнообразные хорошие названия.
Иногда, скажем, в коммент можно запихнуть zen-coding-разметку
0
В следующей части как раз сказано о том, что не стоит комментировать очевидные вещи, и в целом рассказано о том, что и как комментировать.
0
Про БЭМ он знает: cssguidelin.es/#bem-like-naming
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CSS GuideLines, часть 1. Синтаксис и форматирование