Коллеги, стартуем новый проект и составляем рекомендации по разработкам. Традиционно берем старые регламенты и адаптируем их.
Но сейчас решил прибегнуть к помощи вселенского разума: какие рекомендации по вы могли бы дать по именованию объектов разработки?
Что вас мучало долгие годы в названиях объектов? Используете ли вы префиксы (E, D, S, T etc) для объектов словаря? Используете ли вы общий префикс для проекта? Есть ли у вас любимый гайд по именованию? Используете lv_ или l_ для локальных переменных?
Не стесняйтесь дать волю своим чувствам

PS
«There are only two hard things in Computer Science: cache invalidation and naming things.» © Phil Karlton

все типы попадают в таблицу ddtypes и нельзя создать 2 типа с одинаковым именем,
помимо буквы в типе нужно использовать код разработки,
напр э/д ZEO2CR456AUARA ~ Z+E(тип)+O2CR456(задача)+AUARA(произв.наим.объекта),

imho
комментировать код обязательно, в первую очередь для себя, местами полезно вставить в комментарий стэк вызовов,
когда комментариев больше чем кода это нормально.
в общеиспользуемых разработках можно проставлять префиксы iv_,is_,ev_,ct_.. в параметрах функций и методов,
префиксы lt_ gt_ в коде не использую, использую свои постфиксы и некоторые привычки из-за которых иногда возникают трения с qa

trop, спасибо!
Кстати, всегда интересовало, зачем в названиях объектов словаря указывают тип (например, ZE* для элементов данных)? Ведь элемент данных с доменом сложно перепутать - они же в разных местах используются. Да и в списке объектов в запросе легко различаются благодаря отдельному столбцу с типом?

Да, комментарии помогают иногда довольно сильно. Но еще классно, когда сами сущности называются логично (но это уже редкость).

1) Для типов таблиц (в виде добавления T после префикса проекта) 2) Да 3) Нет. Имхо, g_ и gt_ для глобальных - уже достаточно для различения.

По моему, для переменных необходимо указывать
уровень видимости - local / global
тип объекта - varable / structure / object и т.д.
разделитель указателей от имени "_"
а для таблиц указывать тип( sorted, default и т.д. ) необходимо т.к. изменение типа может повлиять на производительность при различном обращении. В этом случае при изменении типа, придётся изменить имя и соответственно проконтролировать/проанализировать все места где она используется.
то есть таблица наименуется так "ltd_tab" или "lts_tab".


я думаю, что для отделения ЭД от структур таблиц и т.д.

Меня все эти годы мучило ограниченное стандартное форматирование ABAP-текста - либо большими буквами, либо маленькими. Что это не читабельно я уяснил ещё в конце 80-х, программируя на Turbo Pascal. Даже какие-то статьи в компьютерных журналах были на эту тему, в которых рекомендовалось использовать длинные имена в стиле "CamelCase".
Поэтому, когда пришлось писать на ABAP, я тоже пытался следовать этим правилам, но всегда находился какой-нибудь "товарищ", который одним нажатием "Структурная печать" (Pretty Printer) сносил все мои старания - слова сливались в сплошную абракадабру. Разделение слов в переменной символом подчёркивания "_" тоже ненамного улучшает читабельность, а часто используемые префиксы (типа "LS_", "GT_" и т.д.) ещё больше загромождают текст.
Недавно, после очередного "товарища", я не выдержал и написал свою "Программу форматирования ABAP-кода", позволяющую автоматически форматировать в заданном стиле, и имеющую гибкие настройки для формирования словаря исключений. Например, чтобы аббревиатуры печатались большими буквами (ABAP, ALV, GUI и т.д.), а известные префиксы маленькими (ls_*, gt_* и т.д.).
В своей системе я расширил стандартный ФМ PRETTY_PRINTER и теперь даже какое-то наслаждение испытываю, когда пишу свои разработки. На проектах, т.к. нет возможности воткнуть расширение, просто запускаю в отдельном режиме и форматирую текст в буфере обмена.