Ниндзя-код

01.04.24

Разработка - Рефакторинг и качество кода

Предлагаю вашему вниманию советы мастеров древности. Программисты прошлого использовали их, чтобы заострить разум тех, кто после них будет поддерживать код. Гуру разработки при найме старательно ищут их применение в тестовых заданиях. Новички иногда используют их ещё лучше, чем матёрые ниндзя. Прочитайте их и решите, кто вы: ниндзя, новичок или, может быть, гуру? (Адаптация статьи "Ниндзя-код" из учебника JavaScript)
 
 Анонс
 
 Адаптация статьи "Ниндзя-код" из учебника JavaScript
 
 Осторожно, ирония!

 Многие пытались пройти по пути ниндзя. Мало, кто преуспел.

Краткость – сестра таланта!

Пишите «как короче», а не как понятнее. Покажите, насколько вы умны!

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

Обратите внимание на тернарный оператор '?', например:

сч = ?(сч < ?(Макс(сч, дл + сч), сч, 0));

Разработчик, встретивший эту строку и попытавшийся понять, чему же всё-таки равно сч, скорее всего, придёт к вам за разъяснениями. Смело скажите ему, что короче – это всегда лучше. Посвятите и его в пути ниндзя. Не забудьте вручить Дао дэ цзин.


Однобуквенные переменные

Кто знает — не говорит. Кто говорит — не знает.

Лао-цзы

Ещё один способ писать быстрее – использовать короткие имена переменных. Называйте их а, б или в.

Короткая переменная прячется в коде лучше, чем ниндзя в лесу. Никто не сможет найти её, используя функцию «Поиск» текстового редактора. Более того, даже найдя – никто не сможет «расшифровать» её и догадаться, что она означает.

…Но есть одно исключение. В тех местах, где однобуквенные переменные общеприняты, например, в счётчике цикла – ни в коем случае не используйте стандартные названия сч. Где угодно, только не здесь!

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

Эффективность этого подхода особенно заметна, если тело цикла занимает одну-две страницы (чем длиннее – тем лучше).

В этом случае заметить, что переменная – счётчик цикла, без пролистывания вверх, невозможно.


Используйте сокращения

Если правила, принятые в вашей команде, запрещают использовать абстрактные имена или имена из одной буквы – сокращайте их.

Например:

СписокЗначений => СЗ
НаборЗаписейРегистра => НЗ
СтрокаТаблицыЗначений => Стр
…и т.д.

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


Будьте абстрактны при выборе имени.

Лучший кувшин лепят всю жизнь,
Высокая музыка неподвластна слуху,
Великий образ не имеет формы.

Лао-цзы

При выборе имени старайтесь применить максимально абстрактное слово, например Спр, Док, Строчка, Значение, МассивДанные, Элемент и т.п.

Идеальное имя для переменной: Данные. Используйте это имя везде, где можно. В конце концов, каждая переменная содержит данные, не правда ли?

…Но что делать, если имя Данные уже занято? Попробуйте Значение, оно не менее универсально. Ведь каждая переменная содержит значение.

Называйте переменную по типу данных, которые она хранит: Стр, Число

Попробуйте! Сделают ли такие имена интереснее разработку? Как ни странно, да и намного!

Казалось бы, название переменной содержит информацию, говорит о том, что в переменной – число, объект или массив… С другой стороны, когда непосвящённый будет разбирать этот код – он с удивлением обнаружит, что информации нет!

Ведь как раз тип легко понять, запустив отладчик и посмотрев, что внутри. Но в чём смысл этой переменной? Что за массив/объект/число в ней хранится? Без долгой медитации над кодом тут не обойтись!

…Но что делать, если и эти имена закончились? Просто добавьте цифру: Данные1, Элемент2, Значение5


Проверка внимания

Только истинно внимательный программист достоин понять ваш код. Но как проверить, достоин ли читающий?

Один из способов – использовать похожие имена переменных, например, Строка и Строчка.

Бегло прочитать такой код почти невозможно. А уж заметить опечатку и поправить её… Ммммм… Мы здесь надолго, время попить чайку.


Хитрые синонимы

Очень трудно найти чёрную кошку в тёмной комнате, особенно, когда её там нет.

Конфуций

Чтобы было не скучно – используйте похожие названия для обозначения одинаковых действий.

Например, если метод показывает что-то на экране – начните его название с Показать.. (скажем, ПоказатьЭлемент), а в другом месте объявите аналогичный метод как Вывести.. (ВывестиНадпись).

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

По возможности, договоритесь с членами своей команды. Если Вася в своих модулях/объектах использует Показать.., то Валера – обязательно Вывести.., а Петя – Отобразить...

…И напротив, если есть две функции с важными отличиями – используйте одно и то же слово для их описания! Например, с Вывести... можно начать метод формирования печатной формы ВывестиОтчет, а также – метод вывода текста в окно диалога ВывестиТекст.

А теперь пусть читающий код думает: «Куда же выводит сообщение ВывестиСообщение?». Особый шик – добавить элемент неожиданности. Пусть ВывестиСообщение выводит не туда, куда все, а в новое окно!


Повторно используйте имена

Когда целое разделено, его частям
нужны имена.
Уже достаточно имён.
Нужно знать, когда остановиться.

Лао-цзы

По возможности, повторно используйте имена переменных, функций и свойств. Просто записывайте в них новые значения.

Добавляйте новое имя, только если это абсолютно необходимо. В функции старайтесь обойтись только теми переменными, которые были переданы как параметры.

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

Цель – развить интуицию и память читающего код программиста. Ну, а пока интуиция слаба, он может построчно анализировать код и конспектировать изменения переменных для каждой ветки исполнения.

Продвинутый вариант этого подхода – незаметно (!) подменить переменную на нечто похожее, например:

функция НинзяФункция(Элемент)

  // 20 строк кода, работающего с Элемент

  Элемент = СоздатьКопию(Элемент);

  // ещё 20 строк кода, работающего с Элемент

КонецФункции


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

Регулярные встречи с этим приёмом на практике говорят: защититься невозможно. Эффективно даже против опытного ниндзи.


Добавляйте подчёркивания

Добавляйте подчёркивания _ и __ к именам переменных. Например, _имя или __значение. Желательно, чтобы их смысл был известен только вам, а лучше – вообще без явной причины.

Этим вы достигните двух целей. Во-первых, код станет длиннее и менее читаемым, а во-вторых, другой программист будет долго искать смысл в подчёркиваниях. Особенно хорошо сработает и внесёт сумятицу в его мысли, если в некоторых частях проекта подчёркивания будут, а в некоторых – нет.

В процессе развития кода вы, скорее всего, будете путаться и смешивать стили: добавлять имена с подчёркиваниями там, где обычно подчёркиваний нет, и наоборот. Это нормально и полностью соответствует третьей цели – увеличить количество ошибок при внесении исправлений.


Покажите вашу любовь к разработке

Пусть все видят, какими замечательными сущностями вы оперируете! Имена СуперЭлемент, МегаСтрока и ЛучшийЭлемент при благоприятном положении звёзд могут привести к просветлению читающего.

Действительно, с одной стороны, кое-что написано: Супер.., Мега.., Лучший... С другой – это не несёт никакой конкретики. Читающий может решить поискать в этом глубинный смысл и замедитировать на часок-другой оплаченного рабочего времени.


Перекрывайте внешние переменные

Находясь на свету, нельзя ничего увидеть в темноте.
Пребывая же в темноте, увидишь все, что находится на свету.

Гуань Инь-цзы

Почему бы не использовать одинаковые переменные внутри и снаружи функции? Это просто и не требует придумывать новых имён.

Перем Пользователь = ТекущийПользователь();

функция ВыполнитьОбработку(Пользователь) 
  ...
  ...
  ...
  ...многобукв...
  ...
  ... // <-- программист захочет внести исправления сюда, и...
  ...
КонецФункции



Зашедший в середину метода ВыполнитьОбработку программист, скорее всего, не заметит, что переменная Пользователь локально перекрыта и попытается работать с ней, полагая, что это – результат ТекущийПользователь()… Ловушка захлопнулась! Здравствуй, отладчик.


Внимание… Сюр-при-из!

Есть функции, название которых говорит о том, что они ничего не меняют. Например, ЭтоСтрока(), ПроверитьПравоДоступа(), НайтиПотомков()… Предполагается, что при вызове они произведут некие вычисления или найдут и возвратят полезные данные, но при этом их не изменят. В трактатах это называется «отсутствие сторонних эффектов».

По-настоящему красивый приём – делать в таких функциях что-нибудь полезное, заодно с процессом проверки. Что именно – совершенно неважно.

Удивление и ошеломление, которое возникнет у вашего коллеги, когда он увидит, что функция с названием на Это..., Проверить... или Найти... что-то меняет – несомненно, расширит его границы разумного!

Ещё одна вариация такого подхода – возвращать нестандартное значение.

Ведь общеизвестно, что Это… и Проверить… обычно возвращают Истина/Ложь. Продемонстрируйте оригинальное мышление. Пусть вызов ПроверитьПравоДоступа возвращает не результат Истина/Ложь, а структуру с результатами проверки! А что, полезно.

Те же разработчики, кто попытается написать проверку Если ПроверитьПравоДоступа(..) Тогда, будут весьма удивлены результатом. Ответьте им: «Надо читать документацию!». И перешлите эту статью.

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


Мощные функции!

Дао везде и во всём,
и справа, и слева.

Лао-цзы

Не ограничивайте действия функции тем, что написано в её названии. Будьте шире.

Например, функция ПроверитьКорректностьEmail(email) может, кроме проверки e-mail на правильность, выводить сообщение об ошибке и просить заново ввести e-mail.

Выберите хотя бы пару дополнительных действий, кроме основного назначения функции. Главное – они должны быть неочевидны из названия функции. Истинный ниндзя-разработчик сделает так, что они будут неочевидны и из кода тоже.

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

Представьте, что другому разработчику нужно только проверить адрес, а сообщение – не выводить. Ваша функция ПроверитьКорректностьEmail(email), которая делает и то и другое, ему не подойдёт. И он не прервёт вашу медитацию вопросами о ней.

 

Итого

Все советы выше пришли из реального кода… И в том числе, от разработчиков с большим опытом. Возможно, даже больше вашего, так что не судите опрометчиво ;)

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

Подготовлено к 1 апреля!
С праздником!

Вступайте в нашу телеграмм-группу Инфостарт

Юмор Вредные советы Ирония Ниндзя Дзен

См. также

HighLoad оптимизация Рефакторинг и качество кода Программист Бесплатно (free)

Рассказываем о том, как не ухудшить производительность интеграционного решения в процессе разработки и рефакторинга, когда новых фич в коробке все больше, а требования по производительности все выше. На живом примере покажем реализованный подход с использованием таких инструментов, как Docker, Redash, Vanessa Automation.

02.09.2025    1580    user1827916    1    

3

Рефакторинг и качество кода Программист Россия Бесплатно (free)

GRASP-паттерны в 1С: меньше хаоса, больше архитектуры.

28.08.2025    7863    lapinio    46    

55

Рефакторинг и качество кода Программист 1С v8.3 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

Недавно наша команда завершила разработку (на несколько тысяч часов) на проекте по внедрению ERP. Заказчик на этом проекте настоял на том, чтобы вся разработка была выполнена в расширениях. Расскажу, с чем столкнулись на 24-25-ых версиях платформы и какие выводы сделали.

19.08.2025    2795    ovetgana    0    

12

Тестирование QA Рефакторинг и качество кода Программист Бесплатно (free)

За два года ручного тестирования решений на базе платформы 1С я столкнулся с огромным количеством ошибок. Глубокий анализ их причин позволил выделить ТОП-5 наиболее частых источников сбоев в 1С-разработке. Понимание этих коренных причин – первый шаг к их предотвращению. В этой статье я делюсь своими наблюдениями и предлагаю практические пути снижения рисков для каждого типа ошибок.

12.08.2025    2236    Lagger117    3    

3

Рефакторинг и качество кода Программист Бесплатно (free)

Рассказываем о практике Code Review: ее целях, преимуществах и подводных камнях. Автор делает обзор существующих инструментов, а также подробно описывает собственную разработку для анализа правок и комфортного взаимодействия по замечаниям. Инструмент Git Code Review позволяет оставлять ручные комментарии с указанием важности и автоматически проверять код с помощью BSL Language Server. С его помощью можно не только детально изучать измененный код, но и отслеживать трансформацию структуры метаданных в наглядном формате. А главное – Code Review можно проводить как в 1С:Предприятии, так и через специализированный веб-интерфейс, интегрированный с GitHub и GitLab. Статья будет интересна и тем, кто уже практикует Code Review, и тем, кто к этому только подступается.

31.07.2025    5005    salexdv    9    

36

Рефакторинг и качество кода Обновление 1С Программист 1С v8.3 Бесплатно (free)

Проблемы и их решение из реальных проектов сложного обновления 1С, когда нужно было сохранить целостность данных, ускориться и уложиться в оцененные и утвержденные сроки.

02.07.2025    4689    1c-izh    9    

13

Рефакторинг и качество кода Информационная безопасность Пароли Программист 1С v8.3 Россия Абонемент ($m)

Представьте ситуацию: вы пишете обработку для отправки email-уведомлений клиентам. Чтобы подключиться к серверу почты, вам нужны: логин, пароль, SMTP-адрес. Что делает большинство программистов?

1 стартмани

23.06.2025    3323    markbraer    8    

3

Рефакторинг и качество кода Инструментарий разработчика Программист 1С v8.3 Абонемент ($m)

Обработка позволяет анализировать структуру методов в модуле и легко составлять её структуру, канонизировать, используя стандарты 1С.

3 стартмани

20.06.2025    2051    21    MikeLetto    3    

10
Отзывы
3. support 4480 01.04.24 17:37 Сейчас в теме
Остальные комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. ixijixi 2048 01.04.24 10:29 Сейчас в теме
О, я недавно встретил ниндзю)

Разбирал пакетный запрос, в котором разработчик увековечил свое имя (пусть будет Сергей). Так вот, он последовательно создавал временные таблицы по шаблону ВТ_Данные_Сергей1, ВТ_Данные_Сергей2, и так до 6-й итерации.

Пришлось попотеть над запросом))
kaaasteeen; Tavalik; Vinzor; Andreev.a; user1158788; sapervodichka; DrAku1a; ivanov660; 0x00; EvgeniyOlxovskiy; +10 Ответить
2. A1WEB 59 01.04.24 14:07 Сейчас в теме
Ещё встречал забавный вариант, когда некий персонаж ни с того ни с сего использует англоязычный вариант языка 1С, включая зарезервированные слова. И всё это в типовой русскоязычной бухгалтерии.
kaaasteeen; user1158788; chesnokov-a-v; lostcay; DrAku1a; +5 Ответить
3. support 4480 01.04.24 17:37 Сейчас в теме
4. DmitryKSL 175 01.04.24 17:44 Сейчас в теме
Называйте переменную по типу данных, которые она хранит: Стр, Число…

При переборе строк постоянно использую "Стр", это плохо?
user1158788; siamagic; +2 Ответить
5. bulpi 217 01.04.24 21:42 Сейчас в теме
(4)
Это не плохо. А вот с чувством юмора не очень :)
9. siamagic 03.04.24 21:07 Сейчас в теме
(4)
нно использую "Стр", эт

Это обычный итератор в любом языке программирования и математике, поскольку автор гуманитарий, итератор должен максимально описывать контекст для подобных людей, т.е. иметь вид: НомерСтрокиТаблицыСотрудниковДляРасчетаЗарплаты = НомерСтрокиТаблицыСотрудниковДляРасчетаЗарплаты +1;
user1158788; +1 Ответить
10. user1158788 04.04.24 12:58 Сейчас в теме
(9) в одном проекте в стандартах разработки ввели ограничение - не сокращать переменные. И в коде были переменные по типу ТаблицаЗначенийСотрудникиДляРасчетаЗарплатыКопия
6. AntonProgma 50 02.04.24 08:12 Сейчас в теме
В случае 1С ещё имена не должны совпадать с их синонимами.

И лучше указать разные версии в имене, синониме и специальном свойстве.
DrAku1a; brr; +2 Ответить
7. DrAku1a 1772 02.04.24 08:48 Сейчас в теме
(6) Зачёт.
Например: Справочник "Номенклатура", синоним "Товары", специальное свойство "Продукция".
8. Дмитрий74Чел 249 03.04.24 19:19 Сейчас в теме
В разделе "Перекрывайте внешние переменные" отсутствует переопределение переменной.
11. Vinzor 116 08.04.24 08:59 Сейчас в теме
В выборке результата запроса обычно применяю переменную "Рез".
Во-первых, это сокращение от "результат (запроса)".
Во-вторых, когда выборка содержит с десяток полей, которые надо структурой загнать в массив (в цикле обхода), то написать в строке образования фиксированной структуры "Рез.Сотрудник, Рез.Сумма, Рез.Период и так далее" гораздо компактнее, чем переменная была бы длинной или многословной.
Хожу на грани нинзя-кода ))
12. kavg 08.04.24 09:06 Сейчас в теме
Автору ДЗ - выяснить у "древних" причины такой формы записи.
Если лень - то да, просто вешаем ярлык: "древние = тупые"
13. Tavalik 3441 08.04.24 09:25 Сейчас в теме
Позабавило, спасибо.

К сожалению, приходилось встречать код ниндзя-программистов. Мне конечно, еще учиться и учиться...
14. starik-2005 3188 10.04.24 11:38 Сейчас в теме
Ох уж эти борцы за права переменных иметь достойное имя...
Методология Agile говорит о том, что не нужно пытаться с первого раза создать сложный и безупречный продукт — пока мы будем его совершенствовать, нас могут обогнать маленькие и шустрые конкуренты. К моменту, когда мы завершим весь цикл работ, наш проект может стать никому не нужен либо его концепция устареет. А денег, времени и сил будет потрачено много.
Ну и
Тезис №5. Agile и микроконтроль несовместимы
15. timeforlive 16 14.04.24 06:07 Сейчас в теме
Если ниндзя, то имена переменных делай китайскими иероглифами. Один символ - а столько смысла.
DrAku1a; dmb2006; +2 Ответить
Для отправки сообщения требуется регистрация/авторизация