В последнее время мне много приходится работать с чужим кодом, и я обратил внимание, что некоторые разработчики любят чрезмерную многословность. Вместо того чтобы сокращать код, они его раздувают ненужными синтаксическими конструкциями. В результате простейшая вещь превращается в словесный небоскреб, тяжело поддающийся первичному визуальному анализу. Ниже я привел несколько таких ситуаций на примере кода из конфигурации для платформы 1С:Предприятие 8.2.
Неоправданное использование массивов
К таким вещам я придираюсь больше всего. Рассмотрим пример: в функции требуется определить значения по умолчанию для ряда реквизитов. Пытаясь решить задачу в лоб, получаем перл вроде этого:
Массив = Новый Массив;
Массив.Добавить("ЗначениеРекивита1");
Массив.Добавить("ЗначениеРеквизита2");
и т.д.
Потом разработчик делает «возврат Массив», и вторая часть перла начинается в приемнике результата:
Филиал = Массив[0];
Подразделение = Массив[1];
…
Будет больше реквизитов, будет длиннее портянка. Проблема этого кода не столько в чрезмерной длине, сколько в восприятии. Откуда я должен узнать, что в нулевом элементе массива хранится значение для реквизита «Филиал»? Этим же вопросом будет наверняка задаваться и автор такого кода, т.к. через полгода он однозначно забудет порядок элементов в массиве. Горемыке придется ковырять отладчиком функцию, формирующую массив, и отлавливать кучу багов при необходимости изменения списка заполняемых реквизитов.
На прошлой неделе мне довелось вдоволь поработать с подобными вещами и ничего не оставалось, как просто переписать некрасивые участки. Разбираться в мыслях автора слишком долго и проще сразу искоренить проблему тотально.
Кстати, решений вышеозвученной абстрактной задачи как минимум несколько. Хочешь, применяй таблицу значений с именованными колонками, хочешь, юзай список значений, ну а любителям массивов стоит строить свое творение из структур. Читабельность кода на порядок улучшится и заполнение можно сделать полностью автоматическим. Достаточно будет пробежаться в цикле по коллекции и установить значения реквизитам.
Булевские реквизиты
Вот этот перл как раз относится к категории «излишняя многословность». Представим, у нас есть реквизит типа «булево». Для простоты примера пусть им будет выступать стандартный реквизит документа «Проведен». Нам требуется написать функцию, возвращающую значение данного реквизита. Смотрим «крутое решение» в лоб:
Если Проведен = Истина Тогда
Возврат Истина;
Иначе
Возврат Ложь;
КонецЕсли;
Автор проверяет истинность условия и возвращает результат. Вроде ничего криминального, но ведь проще написать так:
Возврат Проведен;
Все, без всяких многословных конструкций «если..тогда..иначе» вернули результат (а он всегда будет ИСТИНА или ЛОЖЬ) и забыли. Четыре строчки сократились в одну и избавили колесико мышки от лишнего дергания.
Конструкции «если..тогда..иначе» для многих как манна небесная. Ее стараются применять везде и всюду, без вынужденной необходимости. Смотрим еще один пример:
Если Выборка.Количество() > 0 Тогда
Возврат Истина;
Иначе
Возврат Ложь;
КонецЕсли;
Условие немного другое, но его тоже можно свести к строке:
Возврат Выборка.Количество() > 0;
Такая строка смотрится более красиво, и сразу ясно, что она делает. Никакие лишние операторы ее не окружают.
Копирование значений свойств
Последней в разборе полетов будет проблема многословности при массовом заполнении свойств. Например, у нас есть вот такая структура:
Структура("Филиал, Подразделение, Автор", "Хабаровск", "Первое", "Иванов");
Нам требуется добавить строку в табличную часть (неважно какую) и заполнить одноименные реквизиты. Тут шикарный простор для творчества:
НоваяСтрока = ТабличнаяЧасть.Добавить();
НоваяСтрока.Филиал = НашаСтруктура.Филиал;
НоваяСтрока.Подразделение = НашаСтруктура.Подразделение;
…
или так:
Перебираем в цикле все реквизиты и пишем что-то вроде:
НоваяСтрока[КлючСтруктуры] = ЗначениеСтруктуру;
Но лучше всего сделать так:
ЗаполнитьЗначенияСвойств(ТабличнаяЧасть.Добавить(), НашаСтруктура);
Всего одна строчка заменяет кучу лишней писанины. Встроенная в язык функция «ЗаполнитьЗначенияСвойств» — мощная вещь, и ей надо активно пользоваться при необходимости копирования значений свойств из источника в новый приемник.