Сэр, но как?
Куда оно денется? Даже если сделать автоматическую подстановку значений в код шаблона, большая часть таких алгоритмов все-равно работает с условиями, циклами и прочими сложностями. Ну то есть этот алгоритм никуда не исчезнет чудесным образом. Делать компонент для каждого LI тоже не вариант. Это явно проигрывает варианту с js библиотекой темплейтинга.
У меня есть гипотеза о невозможности построения простых гипотез в отношении поисковой выдачи :)
Выдача последнее время несистематична. То есть она конечно систематична, но на таком уровне сложности, что делать предположения о выдаче стало невозможно. Она подстраивается под поведение пользователей, которое зависит от неизвестных нам факторов. И подстраивается настолько, что становится настолько же сложной и даже сложнее, потому что собирает и накапливает статистику. И выдача на два рядом стоящих почти одинаковых запроса может отличаться совершенно непонятным и неожиданным образом.
Как следствие перестали работать режект-слова в поисковом запросе. Как не добавляй, характер выдачи этим не меняется.
И плюс еще вы делаете предположения об алгоритмах выдачи в тот момент, когда она меняется. Даже если бы и были закономерности, в переходной период они не действуют.
Еще пример (более подходящий) — у нас есть страница с комментариями к статье на хабре. Вместо того чтобы изобретать велосипед или шаблон внутри js кода или делать скрытый div а потом копировать его, можно один раз создать template и вставлять его на страницу каждый раз с новыми данными по кнопке «Написать».
По сути точно так же оно происходит и сейчас, только не в template, а в div, js или через ajax. Если есть шаблон, то как вы его не назовите он шаблон и есть. И точно так же количество манипуляций не изменится. Мне кажется разница только в том, что раньше мы это делали разными способами, а сейчас эта практика унифицируется.
Но он же не переиспользует общий компонент, а каждый раз создает новые фрагменты документа по указанному образцу. И когда создает фрагмент, получившийся фрагмент не как отдельная сущность, а как набор элементов в дереве элементов документа. Что именно в этом от понятия «компонент»? Мне кажется это типичный шаблон.
Я уже читал несколько статей про эти предлагаемые нововведения. Один момент мне непонятен, почему это называют веб-компонентами? Именно компонентами? С точки браузера это вроде бы не компоненты. Я в статьях не вижу такого, что бы компонент был создан один раз и использовался в нескольких местах. Там везде рисуют создание нового теневого дерева и его элементов при каждом использовании. То есть это теплейтинг поддерживаемый непосредственно в браузере. Правильно я понимаю или что-то упустил?
Ну как бы получается ваш код с ошибками. И ошибки как раз из за применения вашего правила. К примеру, return handleTypeDef(obj); вернет undefine, т.к. в теле функции забыт return. При таком обилии служебного кода не мудрено и запутаться.
то есть если не создавать функцию f2(), от этого кода останется только комментарий, это как раз пример служебного кода. Тут нет реального кода, поэтому трудно судить о проценте служебного относительно реального.
И какой примерно у вас получается процент служебного кода, то есть тех конструкций, которые направлены на соблюдение этого правила? И включая пустые строки между ними, то есть общий процент пространства отданного под повышение удобочитаемости для вас? Если строго соблюдать такое правило, получим до 40% пространства занято под служебный код. Что не может радовать.
Я читал эти отчеты. И мое мнение таково, что из за круглых скобочек внутри сложных условий большинство ошибок такого рода. Сложно отследить в уме парность скобочек и опечятки остаются незамеченными. double-if снижает вероятность появления именно таких ошибок, разделяя и упрощая формулу, там где это возможно.
(Кстати, лично у меня ошибки такого рода примерно одна на 150-200к исходников, мне кажется это довольно хороший показатель, такую частоту ошибок такого рода готов принять.)
Вы можете привести хотя бы один пример? Не пример откровенного и явно видимого ляпа, а пример когда конкретно вот эти конструкции приводят к ошибке, неправильному пониманию? Не какие-то как вам показалось похожие, а именно такие? Пока такого примера не было за долгую практику применения.
Ну вот смотрите, вы кричите «ТОЛЬКО», но ведь и вы применяете редкие исключения из правил тогда, когда это возможно. И вот ваш пример. Поэтому не стоит отвечать так категорично. Вот другой пример: comment_7189622, сам так не делал, но понимаю его.
Сам принцип чтения и восприятия кода человеком приводит к таким элементам, конструкцию которая может восприниматься как единое целое можно записать компактно. Я всего-лишь озвучил еще два момента, когда это возможно. Сделал максимально культурно, предварительно тщательно проверил, оттестировал, предупредил от ошибок. Думаю если бы тот же Кармак на Хабре писал инкогнито, его бы тоже… гхм… да что уж тут, забанили бы вы его. Когда мы внедряли соглашения о форматировании кода, еще когда об этом никто не задумывался и крупные фирмы не использовали, тоже было крикунов просто завались, люди даже увольнялись. А сейчас вот вы кричите в обратную сторону. Может пора бы уже и прекратить и попытаться подумать вместо криков?
Это только если не иметь представление о самом понятии удобочитаемости. Несмотря на то, что удобочитаемость вещь сама по себе субъективна, понятие все-таки объективно. Варианты «в строку», «в столбик», «с отступами и разбивкой» разобраны до косточек и объективно вариант «в столбик» более удобочитаем. Много по этому поводу написано в книгах по полиграфии и дизайну.
Э-э-э… объективные возражения у кого-нибудь будут? Поверьте, каждое ваше высказывание я тщательно взвешиваю и если вы сможете доказать мне неправоту, тут же сам себя и опровергну. Но вот NO не дает почвы для выводов, т.к. укладывается в схему как бездумное и непроверяемое возражение.
Нет, таких проблем не наблюдается. Когда вы пишете такую конструкцию, else нет, вы не пишете скобочки. Когда появляется else пишете скобочки. Проблем нет, никаких, абсолютно.
это ваше субъективное мнение
«Субъективное», это ваше «отвратительно». А если объективно, то две-три однотипных строки визуально одна над другой читаются легче чем те же строки с отступами. Мне кажется «перфекционистский бунт» мешает вам мыслить объективно.
Да, об этом я написал, нельзя если есть else. else означает, что блок уже слишком сложный для цельного восприятия. Четкое правило предохраняет от ошибок.
Попробую пояснить. Речь идет не об экономии в один отступ. Речь идет о том, что такая конструкция в итоге читается как один смысловой блок. Это как читать не по буквам, а целыми словами или иероглифами. То есть переход на следующий уровень восприятия. А про опечатку, это для красного словца.
Тогда это не мой случай. Ничего не могу сказать про ваш вариант, т.к. тестировал только примение double-if на отдельных строках и могу отвечать только за применимость этого варианта.
Куда оно денется? Даже если сделать автоматическую подстановку значений в код шаблона, большая часть таких алгоритмов все-равно работает с условиями, циклами и прочими сложностями. Ну то есть этот алгоритм никуда не исчезнет чудесным образом. Делать компонент для каждого LI тоже не вариант. Это явно проигрывает варианту с js библиотекой темплейтинга.
Выдача последнее время несистематична. То есть она конечно систематична, но на таком уровне сложности, что делать предположения о выдаче стало невозможно. Она подстраивается под поведение пользователей, которое зависит от неизвестных нам факторов. И подстраивается настолько, что становится настолько же сложной и даже сложнее, потому что собирает и накапливает статистику. И выдача на два рядом стоящих почти одинаковых запроса может отличаться совершенно непонятным и неожиданным образом.
Как следствие перестали работать режект-слова в поисковом запросе. Как не добавляй, характер выдачи этим не меняется.
И плюс еще вы делаете предположения об алгоритмах выдачи в тот момент, когда она меняется. Даже если бы и были закономерности, в переходной период они не действуют.
то есть если не создавать функцию f2(), от этого кода останется только комментарий, это как раз пример служебного кода. Тут нет реального кода, поэтому трудно судить о проценте служебного относительно реального.
(Кстати, лично у меня ошибки такого рода примерно одна на 150-200к исходников, мне кажется это довольно хороший показатель, такую частоту ошибок такого рода готов принять.)
Сам принцип чтения и восприятия кода человеком приводит к таким элементам, конструкцию которая может восприниматься как единое целое можно записать компактно. Я всего-лишь озвучил еще два момента, когда это возможно. Сделал максимально культурно, предварительно тщательно проверил, оттестировал, предупредил от ошибок. Думаю если бы тот же Кармак на Хабре писал инкогнито, его бы тоже… гхм… да что уж тут, забанили бы вы его. Когда мы внедряли соглашения о форматировании кода, еще когда об этом никто не задумывался и крупные фирмы не использовали, тоже было крикунов просто завались, люди даже увольнялись. А сейчас вот вы кричите в обратную сторону. Может пора бы уже и прекратить и попытаться подумать вместо криков?
«Субъективное», это ваше «отвратительно». А если объективно, то две-три однотипных строки визуально одна над другой читаются легче чем те же строки с отступами. Мне кажется «перфекционистский бунт» мешает вам мыслить объективно.