Правила программирования на JavaScript, которые нужно не соблюдать

• Карьеристы в JavaScript
• Двойное равенство против тройного в JavaScript
• Выход из CASE не является "неправильным" в JavaScript
• CASE не приводит к "усложнению функций" в JavaScript
• Всё в одном примере на JavaScript
• Йодиш — это не зло
• Так почему же люди выдвигают такие огульные предположения?
• Постскриптум

Карьеристы в JavaScript.

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

Двойное равенство против тройного в 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!

Иногда люди доходят до того, что делают полные копии массивов, чтобы можно было использовать ===, только чтобы избежать использования ==, когда сравнение выполняется только ОДИН раз. И для чего, чтобы они могли использовать:

value === 0;

... вместо того, чтобы...

value == "0"

Это полная и абсолютная чушь, которая НИЧЕГО не делает для улучшения ясности или качества кода. Чаще всего это приводит лишь к раздуванию кода.

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

Выход из CASE не является "неправильным" в JavaScript.

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

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

CASE не приводит к "усложнению функций" в JavaScript.

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

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

Всё в одном примере на JavaScript.

Возьмем такую простую вещь, как выполнение DOM... ну, знаете, используемую для того, чтобы просто обойти innerHTML и все проблемы, которые он создает?

const
  make = (tag, cmds) => {
    tag = document.createElement(tag);
    if (cmds instanceof Array)
      for (let data of cmds)
        tag.append(make(...data);
    else if (
      cmds instanceof Node ||
      "object" !== typeof cmds
    ) tag.append(cmds);
    else {
      if (cmds.append) {
        if (cmds.append instanceof Array) {
          for (let data of cmds.append) {
            if (row instanceof Array) tag.append(make(...data);
            else append(tag, data);
          }
        } else tag.append(cmds.append);
      }
      if (cmds.attr) Object.assign(tag, cmds.attr);
      if (cmds.style) Object.assign(tag.style, cmds.style);
      /*
        Всегда делайте родителя последним, устаревшие браузеры могут подгадить
        с установкой атрибуты типа type="", когда элемент уже находится в DOM.
      */
      if (cmds.parent) {
        switch (cmds.place) {
          case "after":
            return cmds.parent.parentNode.insertBefore(tag, cmds.parent.nextSibling);
          case "before":
            return cmds.parent.parentNode.insertBefore(tag, cmds.parent);
          case "first":
            return cmds.parent.insertBefore(tag, cmds.parent.firstChild);
        }
        return cmds.parent.appendChild(tag);
      }
    }
    return tag;
  } // make

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

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

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

Йодиш — это не зло.

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

Смех в том, что многие минификаторы - например, closure compiler Google - переключат ваши утверждения на йодиш, потому что многие структуры - typeof является отличным примером - на самом деле минифицируются лучше, если статическое значение стоит первым, потому что это создает более длинные прогоны одних и тех же символов в коде. Именно здесь многие "DRY" ребята облажаются, потому что они настолько сходят с ума, пытаясь не повторяться, что либо делают больше кода, либо делают меньше кода, который не так хорошо минифицируется. Без шуток, можно написать код, который меньше, но плохо сжимается. Большинство схем архивного сжатия имеют... такие проблемы.

Как таковая разница между:

‘object’ == typeof tag

и

typeof tag == 'object'

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

"И поэтому именно терпите неудачу вы" - Мастер Йода

Так почему же люди выдвигают такие огульные предположения?

Легко обвинить в этом глупость, но я предпочитаю списать это на невежество и слепую веру в то, что вам говорят другие. Помните, что я всегда говорю:

Невежда — это не оскорбление, это просто означает, что вы не знаете ничего, что может быть лучше. Мы можем исправить невежество!

Очень часто, когда люди слышат, что что-то плохо по одной причине, они автоматически принимают это за нечестивый ужас, которого следует избегать любой ценой. Вместо того чтобы взвесить все "за" и "против", они превращают "использовать Y вместо X, когда это уместно" в "никогда не использовать X, всегда использовать Y", даже если это никоим образом, ни в какой форме не указано в начальном утверждении!

Это только усугубляется отношением, что "новички слишком глупы, чтобы понять это, поэтому просто делайте это всегда только так и никак иначе". Как это оскорбительно! Если вы понимаете это настолько, что говорите "никогда так не делайте", и вы когда-то были новичком, то с чего вы взяли, что эти люди слишком глупы, чтобы понять это?

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

Мы видим это и в других аспектах JavaScript, например, как "with" является недействительным в "строгом" коде. Почему? Потому что некоторые разработчики JavaScript запутались в своих трусах из-за того, что не могут понять простую конструкцию, которую программисты на C, Pascal, Ada и множестве других языков использовали десятилетиями без проблем. Они используют "глупость новичков" как оправдание для того, чтобы извергать раздутый, трудночитаемый код во имя того, чтобы сделать его более легким для чтения.

То же самое с нынешним отношением "никогда не использовать var". То, что у нас есть больше возможностей с let и const, не означает, что использование var и "только в масштабе функции" не может дать огромных преимуществ.

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

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

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

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

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

Постскриптум.

10 августа 2022 - Переписал большую часть статьи, чтобы отразить современную практику, изменения в отношении к LET/CONST и стрелочным функциям теперь, когда они реально применимы в большем количестве пользовательского интерфейса, и чтобы сделать ее более увлекательным чтением теперь, когда у меня больше опыта в использовании Medium. Вероятно, не повредит, если я также поставлю его в публикацию.

Перевод с английского:
medium.com

Заберите ссылку на статью к себе, чтобы потом легко её найти!
Раз уж досюда дочитали, то может может есть желание рассказать об этом месте своим друзьям, знакомым и просто мимо проходящим?
Не надо себя сдерживать! ;)