Комментарии 24
CSS это декларативный язык, и часто бывает трудно понять — никогда не возникало трудности в понимании чьего либо css
Что какой-то кусок кода зависит от другого куска — это покажет devtools и любая нормальная IDE
Какой эффект повлечет за собой изменение определенной части кода — изменение оформления страницы
Где еще можно использовать кусок кода без появления новых проблем — в селекторе, для которого стили и были описаны
Какие стили наследует определенный элемент — те, что прописаны для его селектора. Firebug/DevTools в помощь
Какие стили могут быть проигнорированы; — Firebug/DevTools в помощь
Где разработчик намеревался использовать код. — это даже не смешно.
Что какой-то кусок кода зависит от другого куска — это покажет devtools и любая нормальная IDE
Какой эффект повлечет за собой изменение определенной части кода — изменение оформления страницы
Где еще можно использовать кусок кода без появления новых проблем — в селекторе, для которого стили и были описаны
Какие стили наследует определенный элемент — те, что прописаны для его селектора. Firebug/DevTools в помощь
Какие стили могут быть проигнорированы; — Firebug/DevTools в помощь
Где разработчик намеревался использовать код. — это даже не смешно.
Зачем каждый раз лезть в Firebug / Devtools и смотреть стили для каждого селектора, если можно один раз закомментировать CSS и не открывать лишних окон?
Я никогда туда не полезу. Ибо знаю свой код как пять рублей. Все просто и понятно. Все эти пляски с комментариями нужны будут лишь при передаче проекта другому человеку, который не сможет тебя спросить: чувак — что это за хрень? Чтобы разобраться в любом новом для тебя css коде проекта — понадобится несколько часов от силы. И то — если проект не маленький. Так лучше пускай новый человек потратит эти несколько часов один раз, чем я на протяжении всей свой работы буду судорожно комментировать весь свой код.
Вот именно, что это надо при передаче проекта другому человеку. Как бы в первой части сказано, что эти рекомендации больше подходят для больших команд разработчиков, а не для тех, кто сам весь проект работает со своим кодом, так что ваша критика несколько неуместна.
В первом же абзаце текста ставятся под сомнение сообразительные качества единственного разработчика со своим же кодом.
В любой нормальной команде для решения подобных задач давно есть решения. БЭМ, Source, бутстрап(прости, господи). Даже богомерзкий бутстрап будет лучшим решением, чем то, что описано с топике.
В любой нормальной команде для решения подобных задач давно есть решения. БЭМ, Source, бутстрап(прости, господи). Даже богомерзкий бутстрап будет лучшим решением, чем то, что описано с топике.
А при чем тут бутстрап? Топик вроде как не о CSS-фреймворках.
Хотя бы при том, что избавляет от насущной проблемы.
От какой-такой проблемы он избавляет? В CSS GudeLines говорится о рекомендациях по оформлению кода, а не о том, что надо использовать какие-то монструозные фреймворки, в которых черт ногу сломит и которые вообще как-то не в тему.
Т.е. БЭМ не монструозная методика? :D
А зачем переводить стрелки на БЭМ? Да, монструозная, но есть и его модификации более легкие. Наверное некорректно сравнивать бутстрап с БЭМ'ом. Так от какой-такой проблемы избавляет бутстрап?
От бессмысленного комментирования верстки.
Вы мигом соглашаетесь с Norlin насчет БЭМ'а, но не выдерживаете малейшей критики того, о чем пишете. Вместо аргументов за использование советов британского чувака без работы пытаетесь найти слабые стороны моих аргументов.
Вы мигом соглашаетесь с Norlin насчет БЭМ'а, но не выдерживаете малейшей критики того, о чем пишете. Вместо аргументов за использование советов британского чувака без работы пытаетесь найти слабые стороны моих аргументов.
Комментирования 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) Вот если все программеры перейдут на такую-то методику и/или будут юзать вот такие инструменты, то вообще ничо комментировать не надо будет
А в целом — оппоненты топикстартера смогли сместить предмет обсуждения из одной сферы в другую, хотя речь изначально вообще не о том шла
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CSS GuideLines, часть 2. Комментирование кода