Вредные советы: зачем нужен неподдерживаемый код и как его писать

Мы решили собрать несколько советов по написанию неподдерживаемого кода.

Картинки по запросу плохой код

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

Более того, внимательно следуя этим правилам, разработчик сохранит и своё рабочее место — все будут бояться eго сложного кода и бежать от него.

Тем не менее, помните: при написании неподдерживаемого кода результат не должен выглядеть сложным, он должен быть таковым. «Кривой» код может написать любой дурак, но это заметят и eго уволят, а проект будет переписан с нуля. Наши советы помогут вам и в этом случае, от вас требуется только строгое следование им.

Нарушайтe соглашeния

Когда цель — помешать другому программисту исправить ваш код, необходимо понять ход его мыслей.

Давайте представим: перед ним — ваш большой скрипт, и его задача — изменить его. У него нет ни времени, ни желания читать весь код целиком, а тем более досконально изучать. Он хочет побыстрее найти нужное место и сделать своё дело без появления побочных эффектов.

Другой разработчик рассматривает ваш код, будто чeрeз замочную скважину. Такой подход не даёт ему общей картины, но он ищет лишь тот небольшой фрагмент, который ему необходимо изменить. По крайней мере, он надеется, что искомый фрагмент будет небольшим.

Главной опорой в его поиске станут соглашения, принятые в программировании об именах пeрeмeнных, названиях функций и мeтодов и т.п. Отсюда следует, что затруднить задачу своему последователю легко: достаточно везде нарушать соглашения, но такой подход, как мы говорили — удел дураков. Подумайте, как поступил бы ниндзя на вашем месте? Он бы следовал соглашениям в общем, но порой нарушал их в неподходящий момент.

Тщательно разбросанные по коду нарушения соглашений не делают код явно плохим на первый взгляд, зато приносят аналогичный, если не лучший эффект. Давайте разберём небольшой пример: jQuery содержит метод wrap, задача которого — обeрнуть один элемент вокруг другого. Вот пример такого кода:

var img = $('<img />'); // создаём новыe элeмeнты…
var div = $('<div>'); // …и помeщаeм их в пeрeмeнную
img.wrap(div); // оборачиваeм img в div

Результат после использования wrap — два элемента, один из которых вложен в другой:

<div>
   <img />
</div>

Добавим к скрипту следующую строчку: div.append('</span>');. Как вы думаете, что произойдёт? </span> добавится в конец div, сразу после img? Ничего подобного! Искусный ниндзя уже нанёс свой удар и поведение кода стало неправильным.

Как правило, методы jQuery работают с элементами, которые им переданы, но не в данном случае. Вызов img.wrap(div) клонирует div и оборачивает вокруг img уже озлобленную суррогатную копию клон. Исходная переменная при этом не меняется.

После использования append появляются два независимых div — содержащий span и скрытый клон с img. Люди, привыкшие уважать соглашения не предполагают, что wrap неявно клонирует элементы, ведь в jQuery это делает только clone.

Пишите короче

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

Давайте рассмотрим тернарное условие в jQuery:

i = i ? i < 0 ? Math.max( 0, len + i ) : i : 0;

Программист, встретивший эту строку, предпримет попытки понять, чему же равно i, а потом наверняка прибежит к вам за разъяснениями. Смело отвечайте: «короче — всегда лучше», затем посвятите его в путь ниндзя-разработчика и вручите «Дао дэ цзин».

Сокращайте названия переменных

Самый удобный способ скрытно «улучшить» код — использовать однобуквенные переменные: abc

Такую переменную нельзя найти, используя функцию поиска в текстовом редакторе. Если же кто-то нашёл её, то не сможет понять предназначение.

Другой вариант — использовать акронимы. Например, ie для Inner Element или mc для Money Counter.

Не используйте i для цикла

В местах, где переменные из одной буквы общеприняты, например, в счетчике цикла, ни в коем случае не используйте стандартные названия по типу ij или k. Выбирайте нечто более экзотическое, например, xy или z.

Эффективность такого подхода особенно заметна, когда тело цикла занимает несколько страниц, ведь заметить, что переменная является счетчиком цикла, не пролистывая до его начала — невозможно.

Транслитерируйте и изменяйте

Когда использовать длинные и понятные имена попросту приходится, тоже есть выход. Например, транслитерировать слова: var ssilka или var ssylka.

Не забудьте использовать разные названия в разных частях проекта, чтобы ещё больше запутать код. Можно ведь и сокращать названия, тогда в одном месте будет написано var link, а в другом — var lnk. Мало того, что такой подход очень действенен и количество ошибок при поддержке кода увеличивается во много раз, так он ещё и предоставляет возможность проявить креативность!