Comments 24
Зачем каждый раз лезть в Firebug / Devtools и смотреть стили для каждого селектора, если можно один раз закомментировать CSS и не открывать лишних окон?
Вот именно, что это надо при передаче проекта другому человеку. Как бы в первой части сказано, что эти рекомендации больше подходят для больших команд разработчиков, а не для тех, кто сам весь проект работает со своим кодом, так что ваша критика несколько неуместна.
А при чем тут бутстрап? Топик вроде как не о CSS-фреймворках.
От какой-такой проблемы он избавляет? В CSS GudeLines говорится о рекомендациях по оформлению кода, а не о том, что надо использовать какие-то монструозные фреймворки, в которых черт ногу сломит и которые вообще как-то не в тему.
А зачем переводить стрелки на БЭМ? Да, монструозная, но есть и его модификации более легкие. Наверное некорректно сравнивать бутстрап с БЭМ'ом. Так от какой-такой проблемы избавляет бутстрап?
Комментирования CSS, а не верстки. В первой части были описаны преимущества единого стиля по оформлению кода при работе в команде. Также там было сказано, что эти рекомендации ни на что не претендуют и автор лично их использовал не на одном проекте.
Да, я соглашаюсь насчет БЭМ'а, но он подходит не всем. Возможно в каком-то проекте и будет лишним делать комментарии, но мое личное мнение таково, что если придется делать комментарии, то в этой статье описаны весьма дельные советы по их оформлению. Вы можете быть несогласны, это дело ваше. Каждый использует то, что хочет, и эти советы не исключение. Хотите — используйте, хотите — нет.
Да, я соглашаюсь насчет БЭМ'а, но он подходит не всем. Возможно в каком-то проекте и будет лишним делать комментарии, но мое личное мнение таково, что если придется делать комментарии, то в этой статье описаны весьма дельные советы по их оформлению. Вы можете быть несогласны, это дело ваше. Каждый использует то, что хочет, и эти советы не исключение. Хотите — используйте, хотите — нет.
Думаю, не следует бросаться в крайности. Для верстки писем и маленьких проектов, конечно, непонятно что комментировать, но в случае большого проекта, комментирование — это спасение. Мне нравятся вот это выступление: tohtml.it/post/72875975026. Опять же почти все системы документирования верстки типа KSS, StyleDocco завязаны на комментарии в css, которые они парсят.
Так что комментарии для активно растущего проекта — это благо.
Так что комментарии для активно растущего проекта — это благо.
Если использовать подход, аналогичный БЭМ (независимые блоки, стили разделены на много маленьких файлов) и адекватное именование классов (а не просто .btn1, .btn2 и т.д.) – то очень редко в стилях возникакет потребность в комментариях.
Согласен. Сам использую такой подход. Только не все любят БЭМ и подобные методологии, к сожалению.
Опять же повторюсь, эти рекомендации не для разработчиков-одиночек, а для тех, кто работает в команде и часто передает свой код другим разработчикам.
В команде ещё более важно писать понятный код. Конечно, если есть строгий стайлгайд, который никто никак не хочет менять – тогда да, всё плохо. Но обычно есть возможность воздействовать на тимлида\руководителя, привести аргументы и т.д. Особенно, учитывая, что это принесёт больше пользы, чем простые комментарии (которые ещё тоже надо «пробить» для обязательного использования, и которые требуют дополнительных временных затрат от разработчиков)
Товарищи, сливающие карму, потрудитесь объяснить причину, пожалуйста.
Видимо, статья не нравится
По-моему очевидно. Уже сколько на хабре было статей про комментарии в коде.
Код должен быть таким, чтобы комментирование было не нужным. Это и про название переменных в javascript, и про логичные классы и селекторы в css (раз уж тема веба затронута).
Нужно не комментарии писать к css (ну куда уж проще язык?), а качественно его писать.
Комментирование можно допускать только в очень небольших объемах, особенно в препроцессорах (LESS, SASS), когда не всегда миксины или сложные конструкции с условиями и циклами легко понять сразу другому человеку. Опять же — если работа идет в команде — для комментирования есть система контроля версий.
Код должен быть таким, чтобы комментирование было не нужным. Это и про название переменных в javascript, и про логичные классы и селекторы в css (раз уж тема веба затронута).
Нужно не комментарии писать к css (ну куда уж проще язык?), а качественно его писать.
Комментирование можно допускать только в очень небольших объемах, особенно в препроцессорах (LESS, SASS), когда не всегда миксины или сложные конструкции с условиями и циклами легко понять сразу другому человеку. Опять же — если работа идет в команде — для комментирования есть система контроля версий.
Вот читаю комменты тут и пробую переложить ситуацию с CSS на программный код. И вот, что получается:
1) А зачам вообще комментировать? Код должен быть самодокументируемый!
2) Стайлгайд это зло, потому что вместо того, чтоб изучать фреймворки и технологии, вы призываете программеров комментарии писать
3) Вот если все программеры перейдут на такую-то методику и/или будут юзать вот такие инструменты, то вообще ничо комментировать не надо будет
А в целом — оппоненты топикстартера смогли сместить предмет обсуждения из одной сферы в другую, хотя речь изначально вообще не о том шла
1) А зачам вообще комментировать? Код должен быть самодокументируемый!
2) Стайлгайд это зло, потому что вместо того, чтоб изучать фреймворки и технологии, вы призываете программеров комментарии писать
3) Вот если все программеры перейдут на такую-то методику и/или будут юзать вот такие инструменты, то вообще ничо комментировать не надо будет
А в целом — оппоненты топикстартера смогли сместить предмет обсуждения из одной сферы в другую, хотя речь изначально вообще не о том шла
Sign up to leave a comment.
CSS GuideLines, часть 2. Комментирование кода