К сожалению, очень часто можно увидеть неаккуратные коды программ  на языке программирования ABAP, особенно если Вы работаете в качестве консультанта. В этом посте Вы можете найти примеры десяти  худших abap-программ. Некоторые из них могут быть спорными, но другие, определенно, - плохими.
 
1. Готовая программа без каких-либо блоков модуляризации.

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

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

Коды с вложенными циклами, один большой цикл с 30 select single внутри, select  *, неконтролируемое число  "read" . Они уменьшают производительность больше, чем вы можете себе представить, поэтому такие констуркции  следует избегать. Вы можете избежать использования  некоторых из них с помощью правильного проектирования и подбора альтернативных вариантов.
 
4. Разработка в продуктивной и тестовых системах. 

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

 
5. Код без  проверки на ошибки и итогов выполнения блоков программы.

Я видел некоторые из этих видов программ, вероятно, считается, что каждый отдельный оператор в коде будет отрабатывать гладко, но это не всегда так. Если в коде вы не находите какие-либо проверки SY-subrc , то это вообще не очень хороший знак.
 
6- Не использование исключений
Очень похоже на пятый пункт,  всегда необходимо рассматривать и внедрять все исключения в программе.
 
7- Копирование огромных шаблонов для каждой программы

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

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

Читаемость программы очень важна, и где закодирована сложная логика очень полезно поставить некоторые комментарии, чтобы объяснить, что именно сделано в этом функционале.
 
10. Слишком много ошибок и предупреждений после проверок в SLIN и SCI  в недавно разработанной программе.

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

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

11. Копирование стандартных программ (От Matthew Billingham). 

При копировании стандартных программ, в каждом обновлении будет разница между скопированной программой   и новой версией скопированной стандартной программы, что влечет дополнительные риски.  Это потребует больших усилий по адаптации новых функциональных возможностей в скопированной программе.
 
12. Написание кода, как 1999 году (от Patrick Weber).
Постоянное использование устаревших выражений очень раздражает.

13. некорректный формат исходного кода. (От Peter Inotai).

Негативно влияет на читаемость кода.

14. Избегайте «Хардкода» (От Tuhin das).

При отображении любого текста в программе мы должны попытаться использовать стандартные тексты и  текстовые элементы насколько это максимально возможно.

15- Использование выражений  exit and commit work в расширениях (от Johnson Ittyerah).
EXIT гарантирует, что любые новые функциональные возможности, которые вы добавляете ниже не могут запускаться, потому что объявлен EXIT. И COMMIT WORK приводит вас к напрасному труду, когда возникает Update ошибка  через некоторое время.
 
 Главный хак: чтобы избежать проблем с кодом чиайте гайдлайны по ABAP программированию (от Horst Keller)

Автор: Gungor Ozcelebi

Источник:

scn.sap.com