Хороший код

Хороший код. 1

Введение. 1

Правила разработки отчетов. 1

Требования к представлению данных. 1

Требования к расшифровке. 1

Требования к usability. 2

Правила построения интерфейсов. 2

Правила написания кода. 2

 

Введение

Книга посвящена моему опыту по организации учета на предприятиях. Основной опыт накоплен на программах семейства 1С (1С7, 1с8), но анализируется и общее применение SQL-баз данных для учета.

Буду благодарен за обратную связь, помощь в редактуре и написании статей, материальную и моральную поддержку.

РАЗДЕЛ: КОДИРОВАНИЕ

Функции

Минимальные проверки типов параметров функций

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

Пример 1:

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

Пример 2:

Массив или значение?

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

Пример 3:

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

Отказ от побочных эффектов в функциях

Часто встречается код, где программисты осуществляют в модуле функции вывод некоторых сообщений пользователю. Это нехорошее решение. Т.к. если понадобится выполнить функцию в чистом виде, без выдачи сообщения, это сделать будет невозможно. Кроме того, если нужно будет поменять текст сообщения, придется менять функцию. А если возникнет задача выводить разные сообщения разным пользователям при одной и той же ситуации (например, на разных языках), возникнет еще более запутанная проблема.

Рекомендуется заменить код вида:

Функция Х(..)

Если ОшибкаУ Тогда

  Сообщить(«Произошла ошибка Y»);

  Возврат ложь;

КонецЕсли;

Возврат истина;

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

На другой код:

Функция Х(..)

Если ОшибкаУ Тогда

  Возврат «Y»;

КонецЕсли;

Возврат «»;

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

 

Функция ПроверкаХ()

Результат = Х();

Если Результат = «Y» Тогда

  Сообщить(«Произошла ошибка Y»);

  Возврат Ложь;

КонецЕсли;

Возврат истина;

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

РАЗДЕЛ: ОТЧЕТЫ

Если данные и структура отчета позволяют, то в отчете должно быть:

Требования к представлению данных

Требования к расшифровке

Требования к usability

РАЗДЕЛ: ИНТЕРФЕЙСЫ

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

  1. Порядок обхода элементов формы должен соответствовать ожиданиям и потребностям пользователям, в идеале – быть настраиваемым пользователем «под себя».
  2. Форма должна нормально отображаться при различном масштабировании, при сворачивании и разворачивании.
  3. Если некоторое действие недоступно, то кнопка для данного действия должна быть или невидимой, или недоступной.
  4. Если поле обязательно для заполнения, то оно должно быть подчеркнуто красной линией. В некоторых случаях поле иногда может быть обязательным, а иногда может быть необязательным для заполнения. В такой ситуации особенно важно подсказывать пользователю, обязательно поле или нет.
  5. Если пользователь вводит некоторый документ, то у него должна быть возможность сохранить в каком-либо виде данный документ, пусть даже в виде черновика, чтобы его труд не пропал даром. Если пользователю нельзя вводить данные, то нужно его предупреждать об этом как можно раньше и не давать заполнять документ.

Хитрости работы со списками

Если в форме присутствует список однотипных элементов:

·         Если можно выполнить какое-либо действие над одним из элементов, то необходима возможность выделить все или несколько элементов и выполнить это действие, а также сбросить выделение.

·         Необходима возможность профильтровать этот список всеми ожидаемыми пользователем способами, т.е. отобрать только нужные элементы, остальные скрыть.

·         Необходима возможность отсортировать список по любой колонке этого списка.

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

 

РАЗДЕЛ: РЕФАКТОРИНГ

Разделение функции

Допустим, есть функция Ф, которая выполняет две операции А и В и нам нужно, чтобы вторая операция В выполнялась не всегда:

Функция Ф()
  А;

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

Некоторые используют такой подход:

Функция Ф(ДелатьВ = истина)
  А;

  Если ДелатьВ Тогда

    В;

  КонецЕсли;
КонецФункции

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

Но это не самый оптимальный путь, правильнее разделить на две функции:

Функция Ф()
  А;

  В();

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

 

Функция В()
  В;

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

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