Слишком часто в веб-разработке хорошие советы превращаются в плохую практику; или, что еще хуже, неверно истолковать и исказить рекомендации спецификации, заявив, что «никогда не делайте альтернативы». Чаще всего в результате получается раздутый код, равносильный хождению по горящей бочке.

В HTML

Это слишком часто встречается в HTML.

STRONG, EM, B и I

Простым примером этого является то, как теги <em> и <strong> следует использовать вместо <i> и <b>, когда их семантическое значение «акцент» и «больше акцента» более уместно с грамматической точки зрения. За последние 20 с лишним лет я слышал всякую чушь, когда люди волшебным образом превращали это в «никогда не используйте <b> и <i>, а некоторые заходили так далеко, что придумывали наглую ЛОЖЬ о выделении жирным шрифтом и курсивом». теги устарели.

HTML должен быть о семантике, говоря, что вещи есть или должны быть в профессионально написанном документе по структурным или грамматическим причинам. С этой целью все четыре из этих тегов имеют разные значения и варианты использования. Когда вы выделяете название организации в юридическом документе жирным шрифтом или название книги курсивом, если оно не <cite>d, вы НЕ применяете «акцент» или «больше акцента» к этому тексту!

Пример этого, сделанный моим другом около 15 лет назад, хорошо иллюстрирует это:

<blockquote>
  <p>
    <i>GURPS,</i> <b>Steve Jackson Games'</b> flagship role-playing game, was first released in 1985. Several licensed adaptations of other companies' games exist for the system, such as <i>GURPS Bunnies and Burrows.</i> However, <b>SJ Games</b> has no connection with <b>Wizards of the Coast</b>, producers of the <i>Dungeons and Dragons</i> RPG. <em>No <i>GURPS</i> content is open-source.</em> <strong>Do not plagiarize <b>SJ Games</b> work!</strong>
  </p><p>
    -- <cite>RoosterBoy</cite>
  </p>
</blockquote>

Тег <i> для названий продуктов, <b> для соответствующих юридических лиц, <em> для выделения, <strong> для еще большего выделения. ЕСЛИ вы этого не понимаете, вас бы оставили в 5-м классе до середины 1980-х годов за то, что вы не сдали экзамен по английскому языку.

Tables for Layout не означает «Никогда не использовать таблицы».

Мы видим один и тот же сломанный менталитет с людьми вверх, вниз, влево и вправо, которые делают их жизнь несчастной и отталкивают пользователей, превращая «не использовать таблицы для разметки» в «никогда не использовать таблицы». Затем они несут бесконечную чепуху о таких вещах, как «время рендеринга» или «время загрузки» и прочую подобную чепуху. Вот совет: если 386SX/25 под управлением Windows 3.1 по коммутируемому соединению может обрабатывать таблицу в IE 4, пожалуйста, молчите о времени рендеринга или времени загрузки в эпоху, когда дешевый китайский смартфон за 80 долларов имеет четырехъядерный процессор с частотой 1,5 ГГц и широкополосное качество. пропускная способность!

Таблицы существуют для табличных данных. Да, использовать их только потому, что «вау-вау, глазу не хватает колонок» — это глупость, и этого следует избегать. Это не означает, что вы злоупотребляете другими тегами для вещей, которые они не значат — например, для неупорядоченных списков — когда у вас есть табличные данные!

Я думаю, что большая часть этого происходит из-за того, что люди ПО-ПРЕЖНЕМУ придерживаются сумасшедшего мышления в отношении презентационной разметки — просто взгляните на мусор, невежественные, некомпетентные и неумелые «фреймворки», использующие классы для воссоздания худшего из HTML 3.2 — в сочетании с тем, что большинство разработчиков не используют семантику как они не узнают, что в таблицу входит больше тегов, чем просто <tr> и <td>! Гораздо меньше создают семантические отношения, такие как атрибуты scope и axis.

Возьмите эту правильно сформированную таблицу тележки:

<table class="shoppingCart">
 <caption>Shopping Cart</caption>
 <thead>
  <tr>
   <th scope="col">Qty</th>
   <th scope="col">Iten</th>
   <th scope="col">Unit Price</th>
   <th scope="col">Price</th>
  </tr>
 </thead>
 <tbody>
  <tr>
   <td>1</td>
   <th scope="row">AMD Ryzen 5 3600</td>
   <td>174.99</td>
   <td>174.99</td>
  </tr><tr>
   <td>1</td>
   <th scope="row">Gigabyte Gaming X X570 Motherboard</th>
   <td>139.99</td>
   <td>139.99</td>
  </tr><tr>
   <td>2</td>
   <th scope="row">G'Skill Ripjaws 32gb (2x16) DDR4 3600 memory kit</th>
   <td>159.99</td>
   <td>319.98</td>
  </tr>
 </tbody>
 <tfoot>
  <tr>
   <th scope="row" colspan="3">
    Shipping<br>
    <em>Free for orders over $100 USD
   </th>
   <td>Free</td>
  </tr><tr>
   <th scope="row" colspan="3">Grand Total (USD)</th>
   <td>634.96</td>
  </tr>
 </tfoot>
</table>

Нет НИКАКОЙ причины не использовать для этого таблицу, но есть люди, полностью убежденные в том, что «таблицы — это зло», потому что они либо повторяют то, что им сказали, и/или не знают о семантической разметке… то есть вся причина HTML вообще существует. Более того, когда альтернативы не могут создать надлежащие семантические ассоциации для невизуальных UA, которые предоставляет атрибут SCOPE, указывающий, на какой оси следует применять <th>.

Примечание: используя семантику, НЕТ причин, чтобы ссать в классах на каждый проклятый TR, TD и TH внутри для подавляющего большинства макетов… то, чего не могут сказать альтернативы вложенных DIV и злоупотреблений списками. Следовательно, таблица — это не только правильная семантическая разметка, но и, как правило, МЕНЬШЕ!

Кроме того, HTML 5 теперь позволяет использовать TFOOT после TBODY, а не до него, что я приветствую. Затем я кричу «вы, идиоты» в W3C, потому что наоборот, теперь это недействительный код… когда TFOOT перед TBODY был сделан по ПРИЧИНЕ!

В JavaScript

Это становится еще хуже, поскольку это «настоящий» язык программирования — Да, верно — люди, использующие его, как правило, еще более педантичны в вещах. Это особенно верно в отношении «профессиональных преподавателей» и «профессиональных студентов», которые настаивают на включении в свой код непрактичных и неуместных «моделей программирования» и «парадигм», независимо от того, подходит ли он для работы.

Двойное равно против тройного.

Плакат ребенка для этого. Вы услышите, как люди превращают «избегайте двойного равенства, когда это важно» в «никогда не используйте ==». Невежественный, глупый и произвольный.

То, как я видел, как разработчики в последнее десятилетие или около того перепрыгивали через «людей и лошадей, обручи и подвязки, наконец, через бочку с настоящим огнем» только для того, чтобы использовать «===» вместо «==», смехотворно абсурдно. во время.

Отличный пример для этого — когда люди получают значение из тега <option> или любого другого элемента формы. Возвращаемый результат всегда является строкой, но когда люди хотят сравнить с числом, а не использовать свободное сравнение, которое всегда работает, они проходят через принудительное приведение типов, потому что «двойное равенство не сравнивает типы». ». ДЕЙСТВИТЕЛЬНО? Нет, на самом деле вы полны навоза.

Почему полный? Потому что 0 != null != undefined != false. Проверь это:

console.log(0 == null); // returns false
console.log(0 == undefined); // returns false
console.log(0 == false); // returns false
console.log(0 == '0'); // returns TRUE!

Я видел, как люди заходили так далеко, что делали полные копии массивов, приведенных к типу, чтобы они могли === просто избежать использования ==, когда они выполняют сравнение только ОДИН РАЗ. Это полная и полная чепуха и НИЧЕГО не делает для улучшения ясности или качества кода. Чаще всего все, что вы делаете, — это раздувание.

Вот почему существует различие между == и ===, и не использовать его «потому что он не сравнивает типы» — полная ерунда в подавляющем большинстве сценариев и кодовых баз. Люди говорят о том, что это «халтурно» или «небрежно», когда альтернативы, которые они предлагают, во много, МНОГО раз хуже.

Dropthrough на CASE не является «неправильным»

На операторы SWITCH и CASE наваливают множество похожих глупостей, одним из худших из которых является ерунда «избегайте проброса», которая является совершенно необоснованной и полной чушью. В дроп-транкинге ничего плохого нет, черт возьми, это одна из причин, по которой стоит использовать switch/case. Тем не менее, каждый проклятый «линтер» по умолчанию жалуется на это.

Это часто упоминается наряду с столь же бессмысленным:

CASE не вызывает «сложности функций»

В то время как понятие сложности функции имеет свои достоинства, люди доводят его до абсурда с подходом «одна функция на каждую проклятую строку кода». Они берут общую простую идею и превращают ее в запутанный беспорядок, применяя ее чрезмерно. Вы можете увидеть это в современных кодовых базах, где люди создают функции или даже целые классы для однострочных действий, один файл на класс или даже на функцию, и в целом превращают то, что должно быть десять строк кода, в несколько десятков, если не сотен.

И НЕТ! Я НЕ говорю о компрометации кода, запутывая его до отдельных загадочных строк. Я говорю, что ваш запутанный подход «функции и классы для всего» чрезмерно усложняет простейшие задачи.

Все в одном примере

Возьмем что-нибудь столь же простое, как подпрограмма make DOM… вы знаете, используется для простого обхода innerHTML и всех проблем, которые он приносит на стол?

function make(tag, commands) {
 tag = document.createElement(tag);
 for (var cmd in commands) {
  var value = commands[cmd];
  switch (cmd) {
   case 'after':
    value.parentNode.insertBefore(tag, value.nextSibling);
    break;
   case 'before':
    value.parentNode.insertBefore(tag, value);
    break;
   case 'content':
    if (value instanceof Array) {
     for (var arr of value) tag.appendChild(arr[0], arr[1]);
    } else tag.appendChild(
     value instanceof Node ?
     value :
     document.createTextElement(value)
    );
    break;
   case 'first':
    value.insertBefore(tag, null);
    break;
   case 'last':
    value.appendChild(tag);
    break;
   case 'content':
    made.appendChild(document.createTextNode(value));
    break;
   case 'style':
    for (var i in value) tag.style[i] = value;
    break;
   case 'className':
    cmd = 'class';
    // YES, DROP-THROUGH!
   default:
    if (
     value instanceof Array ||
     'object' == typeof value ||
     'function' == typeof value
    ) tag[cmd] = value;
    else tag.setAttribute(cmd, value);
  }
 }
 return tag;
} // make

Эта функция НЕ слишком сложна, чтобы ее можно было разбить на отдельные части… и нет ничего плохого в том, чтобы пропускать, чтобы превратить className в class. НИ что плохого в повторном использовании переданного параметра "тег", что-то еще всякие там шмуки, шмендрик и путц по пустякам ворчат.

Помните, если вы не можете сказать ничего приятного, скажите это на идише.

Этот пример даже поднял кое-что еще, на что люди жалуются или избегают зря.

Йодиш не зло

Это еще одна вещь, которую хазереи, известные как «линтеры», часто имеют наглость, чтобы идти на мешугенах. О нет, вы ставите статическое значение перед переменной, ужасы. Серьезно, это повод расстраиваться из-за того, что кто-то делает?!? Виски Танго Фокстрот!

Смех в том, что многие минификаторы, такие как компилятор закрытия Google, переключают ваши операторы на йодиш, потому что многие структуры — отличный пример typeof — на самом деле минимизируются лучше, если статика стоит первой, потому что она создает более длинные серии одних и тех же символов в коде. Именно здесь многие «сухие» люди ошибаются, потому что они сходят с ума, пытаясь не повторяться, они либо делают больше кода, либо делают меньше кода, который также не сжимается. Без шуток, можно написать код меньшего размера, но он плохо сжимается. У большинства схем сжатия архивов есть… проблемы в этом плане.

Таким образом, разница между:

‘object’ == typeof e

И

typeof e == 'object'

По сути, это буксы… за исключением того факта, что первый, если он выполняется более одного раза в сценарии, на самом деле сжимает gzip меньше при развертывании на стороне клиента.

«И именно поэтому ты терпишь неудачу» — Йода

Так почему же люди делают такие общие предположения?

Легко обвинить в этом глупость, но я предпочитаю списывать это на невежество и слепую веру в то, что вам говорят другие. Неосведомленность – это не оскорбление, это просто означает, что вы ничего не знаете. Вы можете исправить неосведомленность.

Много раз, когда люди слышат, что что-то плохо по одной причине, они автоматически предполагают, что это нечестивый ужас, которого нужно избегать любой ценой. Вместо взвешивания всех «за» и «против» они превращают «используйте это, когда это уместно» в «никогда не используйте это, используйте вместо этого это».

Это только усугубляется отношением, что «новички слишком глупы, чтобы понять это, поэтому просто делайте это все время по-другому». Насколько это оскорбительно? Если ВЫ понимаете это достаточно, чтобы сказать «никогда не делайте этого», и вы когда-то были новичком, то с чего вы взялись, говоря, что эти люди слишком глупы, чтобы понять это? Простой факт заключается в том, что обычно это не более чем проекции, потому что они сами на самом деле этого не понимают и просто слепо повторяют то, что им сказали.

Мы видим это и в других аспектах JavaScript, например, в том, что «с» недопустимо в «строгом» коде. Почему? Потому что некоторые JavaScript-разработчики впали в ступор из-за того, что не смогли понять простую конструкцию, которую программисты на C, Pascal, Ada и множестве других языков использовали десятилетиями без проблем. Они используют «глупость новичков» в качестве предлога для того, чтобы выплевывать раздутый, трудный для чтения код во имя облегчения его чтения. То же самое с нынешним горячим и модным превышением границ с дерпи LET и CONST, которые только вызывают перегрузку памяти, преждевременную сборку мусора и нянчат людей, слишком ленивых, чтобы использовать хорошие соглашения об именах и использовать объекты там, где это уместно. То же самое и с нынешними любимыми в СМИ дерьмовыми стрелочными функциями, которые бессмысленно и бессмысленно загадочны, с ними труднее работать, они решают проблемы, которых у вас даже не должно быть, и добавляют раздутые накладные расходы в виде «ничего не вызывается функция».

Это действительно заставляет меня думать, что у меня есть совершенно другое определение слова «легкий»… и, честно говоря, я искренне верю, что ни одно из этих понятий не настолько сложно, чтобы каждый из вас был «слишком глуп», чтобы понять их. ; независимо от того, что утверждают многие из этих «экспертов».

На самом деле, если кто-то говорит вам не делать что-то, потому что «это слишком сложно для новичков», скорее всего, они сами новички; неквалифицированно тявкать на эту тему; так беги. Беги, если твоя жизнь тебе дорога.

Я не думаю, что вы слишком глупы для этого, и это гораздо оскорбительнее всего, что я здесь сказал, чем они кажутся.