Практически любое соглашение об именовании лучше его отсутствия

… а лучше оно потому, что если его придерживаться, то порядок увеличивается, а беспорядок уменьшается.

С практической точки зрения порядок можно увеличивать до момента, когда он уже начинает вредить “поворотливости”.

 

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

Для себя я выделил шесть основных уровней для борьбы с энтропией исходного кода. Переходить к следующему следует только после освоения уроков предыдущих уровней.

Большим вопросом является кому и сколько уровней надо освоить – это каждый коллектив решает для себя.

1. Основные объекты

Как минимум практически всегда вырабатываются внутренние подходы к именованию главных объектов разработки (программы, транзакции и так далее) – иначе уж совсем бардак наступает.

Ну например:

 

2. Вспомогательные объекты

Но вот чем дальше, тем больше хаоса возникает на каждом шаге. Именование вспомогательных объектов также требует согласованного и взвешенного подхода:

 

3. Структура и дизайн

Требуют или согласования, или ориентировки на “образцы” такие технические ньюансы:

 

Здесь нужны рекомендации общего рода, а также некоторый набор программ, которые следует использовать в качестве образцов.

Например, для отчётов следует всегда выделять следующие блоки:

Кроме прочего, можно выделить соглашение по именованию подпрограмм, например:

[действие]_[объект]

Здесь действие – это некоторый глагол (get, select, update, check, delete и так далее), а объект – это сущность, над которой выполняются действия.

4. Технические решения

Использование параллельных технических решений для продуктивных версий приветствоваться не должно.

В качестве примера можно взять такую распространённую фишку как “Экспорт в Эксель”. Так даже и здесь всегда есть простор, где разгуляться фантазии.

Во-первых, использование технического движка. Например:

Во-вторых, место вызова также может быть разным:

В-третьих, место хранения шаблона также может отличаться:

 

5. Кодировка – внешняя красота

Вот посмотришь на чужие программы – столько разного насмотришься…

 

Каждый программист пишет в меру собственного разумения, да и сам я совсем не безгрешен – однако пытаюсь работать над собой.

Можно обратиться к этой статье в качестве одного из образцов Nomen est Omen — ABAP Naming Conventions.

6. Кодировка – духовное наполнение

Перечень работ, которые в фоновом режиме надо выполнять:

Смотрите для примера статьи из серии Ревизия кода.

Опубликовано 04.11.2010 в 14:26 · Автор ivan · Ссылка
Рубрики: ABAP

Написать комментарий