Ну, то есть, вы считаете плохим кодом тот, который работает неправильно или не работает вообще. Мы все тут тоже считаем его плохим кодом, хотя некоторые не считают его кодом вообще. Но еще мы считаем плохим кодом тот код, который сложно читать, в который трудно и долго вносить изменения. Ваш подход тоже неплохой, наверное. Но он позволяет отвечать критикам кода, которые уверяют вас, что где-то код попахивает bad design'ом, мол, отвали, все работает.
Еще раз, наличие ошибок в качественном коде — следствие человеческого фактора. Так что да, это нормально, просто кто-то кого-то недопонял. Опять же, вы сами подтвердили, что не можете описать алгоритма выявления всех ошибок в коде. А значит, любой код, даже тот, который вам кажется безошибочным, может эти самые ошибки содержать.
Конечно, речь идет не о hello world'е (хотя, вы на C писали, например? думаете, сможете написать там идеальный хеловорлд?), а о чем-то посерьезнее.
Мол, качественный код сможет сохранить работоспособность, как можно дольше при изменениях, если в нём изначально меньше ошибок.
Речь не о работоспособности. Речь о способности выдерживать изменения.
Накапливающиеся ошибки? Это еще как? Это когда я пишу код и не правлю баги, потому что fuck you that's why? Не понимаю, увы.
Я, подобно автору и вашему предыдущему оппоненту, считаю, что главный критерий качества кода — его отзывчивость к изменениям. Ошибки — это человеческий фактор, а не фактор кода, результат дурной аналитики задачи, проблема в коммуникации между постановщиком задачи и разработчиком. Что угодно — только не проблема непосредственно кода.
По сути своей, любой программный компонент — это диссипативная система. Постоянно поступающие внешние требования выполняют в ней роль растущей энтропии. Таким образом, единственное, чем можно оценить качество кода — временем. То есть, как долго может программный компонент сопротивляться этой энтропии и не приходить к своей «термической смерти».
Увы, этот критерий работает лишь пост-фактум. Впрочем, многие опытные разработчики способны предсказать, что тот или иной код долго не протянет, кинув на него один взгляд. И наличие/отсутствие ошибок никак не влияют на это, если честно.
У вас, очевидно, какие-то проблемы с женщинами. Впрочем, к делу это явно не относится.
Вы можете привести алгоритм, по которому можно однозначно выделить из кода все его ошибки/недочеты? Предвосхищая ваш ответ о покрытии тестами, уточню — можете ли вы привести алгоритм наиполнейшего покрытия любого кода тестами?
Напоминает каноничную байку про сисадмина, у которого все было сделано так хорошо, что никогда не падало. И уволили его, потому что не работал, гад такой.
На самом деле, такую же задачку давали на первом коллоквиуме по программированию на мехмате в МГУ, у тов. Борисова. Только разве что (с учетом мощности местных компьютеров), были какие-то очень добрые ограничения на ввод. Но это же рандом, нет? Или для выпускников мехмата у вас другие задачки?)
При таком коде проблема в том что браузеру нужно пару раз пройтись по всем ссылкам, коих может быть много, верно?
Я боюсь, вы недооцениваете оптимизацию этих алгоритмов. Не имею сейчас возможности посмотреть код, но почти уверен, что второй раз он не пойдет по дереву. Что касается индексации классов, Webkit (полагаю, Gecko работает схожим образом) занимается этим только на этапе интеграции DOM дерева и распарсенного CSS, в чем, собственно, и заключается построение Layout'а. Это логично, поскольку далеко не все классы, использованные в HTML коде обязательно будут описаны в CSS. Такая небольшая оптимизация, впрочем, вероятно, там есть и более глубокие идеи, которые мне из подвала не видно.
Сами понимаете, индекс по конечному и заранее известному списку допустимых имен тегов нод, отработает несколько быстрее чем индекс по списку всех классов. Но, ЕМНИП, там для таких индексов используется биндерево, а значит разница в производительности станет заметна только на ОЧЕНЬ большом количестве классов на странице.
Итого:
1. Самый быстрый вариант:
.sidebar-link
Это не магия, поскольку будет все понятно. В вашем первом посте мне показалось, что вы вообще на все ссылки в проекте планировали вешать класс «а», что, разумеется, совершенно бессмысленно. Класс, использованный в контексте одного блока будет легко воспроизводим и никак не повлияет на другие части кода.
2. Второй по производительности:
.sidebar a
Проблемы начнут возникать только если в сайдбаре появится еще какая-нибудь ссылка, которая должна выглядеть как все остальные. Придется огребать.
3. Самый долгий:
.sidebar .a
Но разница в производительности не просто ничтожна — вы ее вряд ли выявите на тестах меньше нескольких десятков тысяч нод. Так что не парьтесь и лучше пишите понятный и читаемый код, не парясь за оптимизацию селекторов. По крайней мере, до тех пор, пока ваши селекторы не станут выглядеть как-нибудь так:
div#MyBlock .sideBar + .nextNode#Hello div a > img.classImg
PS: В общем, MDN слушай, а сам не плошай. Есть в статье совет, не использовать селекторы вида
div#id
, дескать, работает неоптимально. Но — вот ужас — в Webkit идентификатор ноды работает с CSS иначе. Если на вашей странице два блока с одним ID и правило CSS с селектором этого ID, они оба отрисуются с использованием этого правила. И работающий с неким индексом селектор # тоже в некоторых случаях отработает дольше чем div#id. У меня, например, в проекте нод с ID на странице встречается просто безумное количество. Они, правда, никогда не участвуют в CSS, но, боюсь, если бы участвовали, селектор div#id был бы не такой уж и медленный ;)
Льщу себе надеждой, что разбираюсь в сути вопроса:
1. Во-первых, крайне мала вероятность ситуации, когда выбор «a» работает с той же скоростью, что и ".a". Я не уверен в том, как работает парсер Gecko для таких случаев, но в Chrome этот парсер работает «лениво» (он не заполняет список классов ноды до тех пор, пока не придет туда при формировании Layout'а) и поскольку крайне редко все элементы на вашей странице обладают одним и только одним классом, получение списка всех нод с TAGNAME A работает несколько быстрее получения всех нод с классом A.
Конечно, сложность не так чтобы вырастает — на не более чем линию.
2. Во-вторых, цитирую вас
особой разницы между .something .a и .something a не будет
Вопрос zorro1211 состоял в ЧЯДНТ. Уверяю вас, разница в процессе разработки существенная — в первом случае чтобы добавить в проект ссылку, нужно просто написать ссылку. Во втором случае придется еще вешать на нее класс «A». Что попахивает магией и вряд ли где-то задокументировано. И даже если задокументировано, все равно плохо.
3. А вообще говоря, быстрее использовать не .something .a и не .something a, а .something-link. Если в этой ноде нет ID, прочих классов, у нее тот же :hover, :active и :link -state, что и у селектора, то она будет гораздо быстрее занимать свое место в Layout.
За исключением того факта, что вновь пришедшему верстальщику придется узнавать магические сведения о том, что все ссылки должны иметь класс «a», а все картинки — «img».
1. Я вот всегда воспринимал стек HTML+CSS+JS как некую верстальщическую MVC: моделью был HTML, вьюхой CSS, контроллером (в некотором роде) JS. Идея отказаться в CSS от всех селекторов, окромя классов, показалась мне очень здравой и не столько из-за быстродействия, сколько из-за того, что это отвязывает «модель» от «вьюхи».
В БЭМе роль модели ложится на стороннюю сущность, а стек HTML+CSS+JS (и прочие) является вьюхой.
Это у меня сейчас были мысли вслух, прошу прощения. Вообще, есть что переосмыслить, но, кажется, все равно все упрется в религию — кому как нравится.
2, 3. Беру свои слова назад, я заблуждался.
Спасибо большое за ваш комментарий, очень информативен и бесстрастен.
Выглядят все эти проблемы, имхо, одинаково — синдром «только что узнал».
Я ничего не имею против БЭМ, какими-то частями методологии старательно пользуюсь сам (например, только селекторы классов), но есть несколько вещей в БЭМ, которые меня заставили от него отвернуться, до тех пор пока кто-то не поменяет что-то в этой идеологии.
1. Сильная связность с каким-то стеком технологий. Можно сколько угодно кричать о том, что это просто методология, но эта методология вовсе не нова; модульность? инкапсулияция? Да причем тут БЭМ вообще? БЭМ — это куча тулзов от яндекса и энтузиастов, а не методология, все остальное придумано не ими, жило и цвело еще до появления этой аббревиатуры.
2. Невозможность покрытия модульными тестами. Честно, я бы рад, наверное, пользовать все это добро для своих проектов, но как для этого тесты писать? А если хочется еще эти тесты как-то с TeamCity связать? Один раз попробовал, лоб разбил, второй раз попробовал — да ну нафиг. Не БЭМом единым, я вполне запросто нативными средствами пишу хороший, модульный, реюзабельный JavaScript.
3. Интеграционные тесты? Окей, понятно уже.
Когда я лет пять назад впервые познакомился с jQuery, я всюду пихал ее, даже где это было не нужно, создавало боттлнеки и делало код нечитаемей. Мне жутко нравились селекторы, и я использовал их по максимуму, не особо задумываясь — а нафига?
Когда я узнал про Generic в C#, я стал пилить такие эпичные портянки с обобщенными интерфейсами, классами, методами, аттрибутами, что теперь уже даже страшно немного.
Ну ладно, когда-нибудь и любители забить гвоздь интернет-магазина на пару тысяч строк кода костылем для огромного проекта на миллионы строк словят своего северного зверька. Осознают, что серебряной пули нет и перестанут противопостовлять верстку руками мегаавтоматизированному сборщику.
Первым делом я попытался вспомнить тот курс, который прослушал в своем вузе: нам рассказывали про базы данных, ориентированные на MS Access, а языку SQL была посвящена всего пара лекций. С тех пор я больше никогда не пользовался MS Access, и ценность приобретенных знаний стремится к нулю.
Поэтому при проектировании своего курса я решил отталкиваться от того, с чем непосредственно работаю в настоящее время сам.
То есть, вы решили полностью повторить ошибку вашего вузовского преподавателя и дать студентам информацию, которая, вероятно, нигде им потом не пригодится?
Математика, в принципе, обладает целым рядом различных ипостасей. Для науки, которая изучает природу математика, действительно, лишь аппарат. Для Анжелы Львовны, поэтессы с богатым внутренним миром и тройкой по математике — это сухой набор формул и вообще для людей без чувства прекрасного.
Но для математиков математика — это чистая фантазия. Коль скоро любая естественная наука обнимает лишь малую часть математики, их взгляд на математику можно считать однобоким, весьма унылым и очень прикладным. Настоящая математика — это не наука в общем смысле: нельзя сформулировать область ее интересов, нельзя адекватно описать математический опыт и так далее.
Фантазия для того, чтобы держать в голове правила и модели, не требуется. Для того чтобы создать их, применять их и открывать их миру — нужна не просто фантазия, а, пардон, ФАНТАЗИЯ.
Возможно, я математический романтик, но мне грустно слышать о том, что математика — это набор правил. Правила в ней — это маленький кусочек проекции математики на околоматематический мир в лучшем случае.
Фантазия и фантазирование, несомненно, разные вещи в силу того, что первое (в данном контексте) — атрибут мыслительной деятельности (даже скорее творческой), а второе (судя по морфологии) — некий процесс, который вы отчего-то наделили негативной окраской.
Вы, вроде как, утверждаете, что Катя и Чернова — это разные вещи, но говорите об одной и той же Кате Черновой.
Если принятый вами на работу сотрудник старательно записывает расположение камер видеонаблюдения, ищет слепые зоны, черные ходы и кассовые аппараты — вы будете вполне правы, уволив его, вне зависимости от его цвета кожи.
Впрочем, увольнять его соседей по подъезду будет уже несколько лишним.
Вот иногда комментарии нужны для прекрасного чувства ностальжи по проведенным в офисе выходным перед новогодним релизом.
Конечно, речь идет не о hello world'е (хотя, вы на C писали, например? думаете, сможете написать там идеальный хеловорлд?), а о чем-то посерьезнее.
Речь не о работоспособности. Речь о способности выдерживать изменения.
Накапливающиеся ошибки? Это еще как? Это когда я пишу код и не правлю баги, потому что fuck you that's why? Не понимаю, увы.
По сути своей, любой программный компонент — это диссипативная система. Постоянно поступающие внешние требования выполняют в ней роль растущей энтропии. Таким образом, единственное, чем можно оценить качество кода — временем. То есть, как долго может программный компонент сопротивляться этой энтропии и не приходить к своей «термической смерти».
Увы, этот критерий работает лишь пост-фактум. Впрочем, многие опытные разработчики способны предсказать, что тот или иной код долго не протянет, кинув на него один взгляд. И наличие/отсутствие ошибок никак не влияют на это, если честно.
Вы можете привести алгоритм, по которому можно однозначно выделить из кода все его ошибки/недочеты? Предвосхищая ваш ответ о покрытии тестами, уточню — можете ли вы привести алгоритм наиполнейшего покрытия любого кода тестами?
Я боюсь, вы недооцениваете оптимизацию этих алгоритмов. Не имею сейчас возможности посмотреть код, но почти уверен, что второй раз он не пойдет по дереву. Что касается индексации классов, Webkit (полагаю, Gecko работает схожим образом) занимается этим только на этапе интеграции DOM дерева и распарсенного CSS, в чем, собственно, и заключается построение Layout'а. Это логично, поскольку далеко не все классы, использованные в HTML коде обязательно будут описаны в CSS. Такая небольшая оптимизация, впрочем, вероятно, там есть и более глубокие идеи, которые мне из подвала не видно.
Сами понимаете, индекс по конечному и заранее известному списку допустимых имен тегов нод, отработает несколько быстрее чем индекс по списку всех классов. Но, ЕМНИП, там для таких индексов используется биндерево, а значит разница в производительности станет заметна только на ОЧЕНЬ большом количестве классов на странице.
Итого:
1. Самый быстрый вариант: Это не магия, поскольку будет все понятно. В вашем первом посте мне показалось, что вы вообще на все ссылки в проекте планировали вешать класс «а», что, разумеется, совершенно бессмысленно. Класс, использованный в контексте одного блока будет легко воспроизводим и никак не повлияет на другие части кода.
2. Второй по производительности: Проблемы начнут возникать только если в сайдбаре появится еще какая-нибудь ссылка, которая должна выглядеть как все остальные. Придется огребать.
3. Самый долгий:
Но разница в производительности не просто ничтожна — вы ее вряд ли выявите на тестах меньше нескольких десятков тысяч нод. Так что не парьтесь и лучше пишите понятный и читаемый код, не парясь за оптимизацию селекторов. По крайней мере, до тех пор, пока ваши селекторы не станут выглядеть как-нибудь так:
PS: В общем, MDN слушай, а сам не плошай. Есть в статье совет, не использовать селекторы вида , дескать, работает неоптимально. Но — вот ужас — в Webkit идентификатор ноды работает с CSS иначе. Если на вашей странице два блока с одним ID и правило CSS с селектором этого ID, они оба отрисуются с использованием этого правила. И работающий с неким индексом селектор # тоже в некоторых случаях отработает дольше чем div#id. У меня, например, в проекте нод с ID на странице встречается просто безумное количество. Они, правда, никогда не участвуют в CSS, но, боюсь, если бы участвовали, селектор div#id был бы не такой уж и медленный ;)
1. Во-первых, крайне мала вероятность ситуации, когда выбор «a» работает с той же скоростью, что и ".a". Я не уверен в том, как работает парсер Gecko для таких случаев, но в Chrome этот парсер работает «лениво» (он не заполняет список классов ноды до тех пор, пока не придет туда при формировании Layout'а) и поскольку крайне редко все элементы на вашей странице обладают одним и только одним классом, получение списка всех нод с TAGNAME A работает несколько быстрее получения всех нод с классом A.
Конечно, сложность не так чтобы вырастает — на не более чем линию.
2. Во-вторых, цитирую вас
Вопрос zorro1211 состоял в ЧЯДНТ. Уверяю вас, разница в процессе разработки существенная — в первом случае чтобы добавить в проект ссылку, нужно просто написать ссылку. Во втором случае придется еще вешать на нее класс «A». Что попахивает магией и вряд ли где-то задокументировано. И даже если задокументировано, все равно плохо.
3. А вообще говоря, быстрее использовать не .something .a и не .something a, а .something-link. Если в этой ноде нет ID, прочих классов, у нее тот же :hover, :active и :link -state, что и у селектора, то она будет гораздо быстрее занимать свое место в Layout.
В БЭМе роль модели ложится на стороннюю сущность, а стек HTML+CSS+JS (и прочие) является вьюхой.
Это у меня сейчас были мысли вслух, прошу прощения. Вообще, есть что переосмыслить, но, кажется, все равно все упрется в религию — кому как нравится.
2, 3. Беру свои слова назад, я заблуждался.
Спасибо большое за ваш комментарий, очень информативен и бесстрастен.
Я ничего не имею против БЭМ, какими-то частями методологии старательно пользуюсь сам (например, только селекторы классов), но есть несколько вещей в БЭМ, которые меня заставили от него отвернуться, до тех пор пока кто-то не поменяет что-то в этой идеологии.
1. Сильная связность с каким-то стеком технологий. Можно сколько угодно кричать о том, что это просто методология, но эта методология вовсе не нова; модульность? инкапсулияция? Да причем тут БЭМ вообще? БЭМ — это куча тулзов от яндекса и энтузиастов, а не методология, все остальное придумано не ими, жило и цвело еще до появления этой аббревиатуры.
2. Невозможность покрытия модульными тестами. Честно, я бы рад, наверное, пользовать все это добро для своих проектов, но как для этого тесты писать? А если хочется еще эти тесты как-то с TeamCity связать? Один раз попробовал, лоб разбил, второй раз попробовал — да ну нафиг. Не БЭМом единым, я вполне запросто нативными средствами пишу хороший, модульный, реюзабельный JavaScript.
3. Интеграционные тесты? Окей, понятно уже.
Когда я лет пять назад впервые познакомился с jQuery, я всюду пихал ее, даже где это было не нужно, создавало боттлнеки и делало код нечитаемей. Мне жутко нравились селекторы, и я использовал их по максимуму, не особо задумываясь — а нафига?
Когда я узнал про Generic в C#, я стал пилить такие эпичные портянки с обобщенными интерфейсами, классами, методами, аттрибутами, что теперь уже даже страшно немного.
Ну ладно, когда-нибудь и любители забить гвоздь интернет-магазина на пару тысяч строк кода костылем для огромного проекта на миллионы строк словят своего северного зверька. Осознают, что серебряной пули нет и перестанут противопостовлять верстку руками мегаавтоматизированному сборщику.
То есть, вы решили полностью повторить ошибку вашего вузовского преподавателя и дать студентам информацию, которая, вероятно, нигде им потом не пригодится?
Но для математиков математика — это чистая фантазия. Коль скоро любая естественная наука обнимает лишь малую часть математики, их взгляд на математику можно считать однобоким, весьма унылым и очень прикладным. Настоящая математика — это не наука в общем смысле: нельзя сформулировать область ее интересов, нельзя адекватно описать математический опыт и так далее.
Фантазия для того, чтобы держать в голове правила и модели, не требуется. Для того чтобы создать их, применять их и открывать их миру — нужна не просто фантазия, а, пардон, ФАНТАЗИЯ.
Возможно, я математический романтик, но мне грустно слышать о том, что математика — это набор правил. Правила в ней — это маленький кусочек проекции математики на околоматематический мир в лучшем случае.
ИМХО.
Вы, вроде как, утверждаете, что Катя и Чернова — это разные вещи, но говорите об одной и той же Кате Черновой.
PS: Прошу прощения за изобилие скобок.
Впрочем, увольнять его соседей по подъезду будет уже несколько лишним.