Данная статья является переводом (с большой долей подсматривания в megamozg) известной статьи с небольшим приложением на мир 1С.
Если бы строители строили дома так же, как программисты пишут программы, первый залетевший дятел разрушил бы всю цивилизацию. Gerald M. Weinberg
Миром правит не тайная ложа, а явная лажа. В. Пелевин
В целях возможности трудоустройства я передаю эти советы из уст мастеров о том, как писать код, который трудно поддерживать, сложно изменить и невозможно понять. Любой программист, который придет после вас, потратит многие месяцы, чтобы сделать простейшие изменения. Более того, следуя этим правилам вы гарантируете себе пожизненную занятость, потому что никто кроме вас, даже находясь в адских агониях, не захочет поддерживать код.
Но вы же не хотите переусердствовать? Ваш код не должен выглядеть безнадежно, хотя является по факту таковым. Ведь существует риск попасть под рефакторинг, а нам оно совершенно ни к чему.
Содержание
Общие правила. Соглашения.
Чтобы помешать другому программисту, вы должны думать как обычный программист. Перед ним ваш гигантский труд. У него нет времени, чтобы прочитать все это и уж точно, чтобы понять. Он хочет быстро найти проблему, внести изменения и уйти, не ожидая побочных эффектов от вмешательства. Он рассматривает ваш код маленькими кусочками, и ваша задача - добиться того, чтобы он даже не смог представить общую картину ваших действий. Но куда важнее, чтобы он не смог игнорировать ни строчки вашего творения.
Программисты тешат себя иллюзиями наличия соглашений. Но каждый раз, слегка нарушая общие правила, вы заставляете его читать каждую букву вашего кода через увеличительное стекло. Хотя, вам может показаться, что любое отклонение делает код неподдерживаемым - но это не совсем правда. Все хорошо в меру. Тщательно разбросанные по коду нарушения имеют даже лучший эффект, чем явное игнорирование правил.
Пример:
Как правило, предполагается что процелура с названием ДополнитьСтруктуруНаСервере(Структура) дополняет некоторые данные в переданную структуру. Достаточно слегка изменить процедуру с учетом особенной платформы и у программиста уже будет некоторая непонятка происходящего:
&НаКлиенте
Процедура Тест_1(Команда)
Структура = Новый Структура;
Структура.Вставить("А", 1);
ДополнитьСтруктуруКлючомБ(Структура);
Структура.Вставить("В", 3);
КонецПроцедуры
&НаСервере
Процедура ДополнитьСтруктуруКлючомБ(знач Структура)
Структура.Вставить("Б", 2);
КонецПроцедуры
Прочитав только процедуру "Тест_1" можно ожидать что на выходе вы получите структуру с ключами А, Б и В. Но не тут то было. На первый взгляд все сделано верно, даже объявление переменной с использованием знач соответствует правилам. В тоже время, вы можете подобный код писать с директивой &НаКлиенте и получить абсолютно ожидаемое поведение и структуру с тремя ключами. Возможно именно подобный пример сделает пару часов работы вашего коллеги особенно приятными.
Ничего лишнего
Значительная часть искусства написания неподдерживаемого кода в именовании объектов метаданных, переменных и методов. Они ничего не значат для платформы и следовательно, предоставляют вам неограниченные возможности для того, чтобы поставить в тупик не одного сопровождающего.
1. Имена детей
Возможно вам стоит приобрести книгу "Как правильно назвать ребенка. 40000 русских и иностанных имен" и у вас никога не будет проблем с именованием переменных. В тоже время "Йцук" прекрасное имя и легко набирается. Если тем не менее вы до сих пор придумываете имена переменных, попробуйте "авыф", "апро", ну или наконец купите себе клавиатуру Дворака.
2. Однобуквенные имена переменных
Если вы называете свои переменные "и", "а", "к", их будет невозможно искать в редакторе. Кроме того, никто не догадается для чего они нужны. Если кто-нибудь упомянет о нарушении традиции называть счетчики циклов простыми буквами, чтимой со времен Fortran, напомните о том, что испанская инквизиция делала с еретиками. Более того, используйте однобуквенные переменные где угодно, кроме счетчиков циклов.
3. "Случайные" опечатки
Если же вы вынуждены использовать описательные переменные, просто "очепятайте" их. Поверьте, неправильное написание в какой-то функции или имени переменной способно свести на нет все удобства использования, не без этого, неудобного редактора от 1С. Добавляйте интернационализацию по вкусу.
4. Будьте абстракты
Используйте абстрактные слова и понятия, вроде "все", "это", "данные", "ссылка" и т.п, аналогично можете использовать цифры: Заполнить1(), ПосчитатьВсе(), ПроверитьЭто().
5. Сокращения (Акронимы)
Настоящие мачо не бояться сокращений, их понимание в крови и передается с молоком матери. Если же вы не знаете как сокращать, называйте ваши переменные осмысленно, а потом используйте глобальную замену, чтобы дать вашим переменным и методам непонятные имена и сокращения, подобно тому как делает обфускатор.
6. Синонимы
Пролистайте словарь или воспользуйтесь фантазией в поисках максимально возможного количества синонимов для одного и того же действия (например: показать, открыть, представить). Используйте их, когда хотите намекнуть, что есть тонкие различия между использованием методов. В тоже время, две подобных функции, которые могут иметь решающее значение, всегда называйте одинаковым словом. Например: "Печать" может означать: вывод печатной формы на экран, скрытую отправку на принтер или даже предварительную запись объекта.
7. Избегайте глоссария проекта
Запомните: написания глоссария - непрофессиональное нарушение принципа структурного дизайна, известного как "сокрытие информации". Если же вы вынуждены его писать, постарайтесь использовать рекурсивные определения. Дразните своего читателя, притворяясь, что вы даете информацию там, где ее нет ни грамма. Формулируйте ваши пустопорожние сентенции так, чтобы читатель испытывал чувство вины за неспособность понять что вы хотите сказать.
И никогда не используется конкретные примеры. Можете вполне оправдываться, что наличие примера будет вводить в заблуждение, будто это и есть все возможности, заложенные в программу. Запомните: люди уважают только то, что слишком абстрактно, чтобы легко понять. В конце концов еще ни одного академика не застали за приведением примеров.
8. Используйте правила других языков
Отлично подойдет любой язык: Клингонский, Вестрон, Дотракийский и даже родной язык ближайшего гоп-стоп района. Вполне можно вспомнить как в детстве вы придумывали слова разбивая на слоги и добавляя любой понравившийся вам слог. Таким образом, вы поддерживаете мир во всем мире.
9. Использование регистра
Можно сколько угодно спорить о правилах 1С относительно прописных букв, но намного лучше ввести собственное правило. Например: выделять псевдослова в переменных или случайным образом выделять прописные буквы. Например: ПараллелоГрамм.
10. Повторное использование переменных
Во всех случаях, допускаемых платформой, давайте переменным, глобальным, клиентским или серверным методам одинаковые имена. Желательно повторно использовать имена реквизитов внутри процедур в качестве имен параметров, переданных для обработки. Это делается для того, чтобы сопровождающий внимательно изучил область действия каждой переменной. Особенно приятно, передавая в функцию переменные А и Б, в объявлении функции поменять их местами; использовать одну переменную для разных целей или просто слегка менять назначение.
11. Подчеркивание, ваш надежный друг
Используйте _и__ в качестве имен переменных. Особенно неплохо работает приписывание их в начало или конец имени переменных, реквизитов или методов. Более того, это в целом не противоречит стандартам 1С.
12. Смешивайте
Пишите на разных языках. Если все в вашей организации пишут на русском, пишите на английском. Можете применять смешанно, например переменные называть на русском, а методы на английском.
13. Специальные или эмоциональные имена
Отлично подходят имена которые выдают себя за определенные объекты: Параметр = (счетфактура - накладная) / проценты. Также можно выбирать имена переменных с неуместным эмоциональным оттенком: Хрень = (половинаХрени - втораяПоловина) / СуперДоля.
14. Игнорируйте соглашения
Это самое простое, компилятор на это не отреагирует. Также можно предложить свои собственные правила, тогда можно обвинять окружающих в их несоблюдении.
15. Ложные имена
Убедитесь, что каждый метод делает чуть больше (или меньше), чем предполагает его название. В качестве простого примера метод ПроверитьЗаполнениеСчетФактуры(СчетФактура) в качестве побочного эффекта может записывать текущую версию документа в базу данных.
16. Ограничения возможностей человека
Просто запомните, человеческий мозг может комфортно обрабатывать не более 7 фрагментов информации одновременно. Пользуйтесь этим. Я думаю вы сами все поняли.
Продолжение следует...
Когда у меня будет в следующий раз хорошее настроение, мы рассмотрим главы:
- Камуфляж (эффективный код, пространства имен, вымышленные функции, имена кода vs интерфейса, параметры сеанса, директивы препроцессора, отвлекающие маневры)
- Документация (ложь во имя времени, только очевидное, "как" (а не "почему"), шаблоны, баги, унижение других, устаревший код)
