Добрый день, Коллеги.

Подскажите, пожалуйста, существуют ли какие-то стандарты написания програмного кода на ABAP?
Иммются ввиду требования к форматированию кода, выравниванию конструкций и пр...
Имею ввиду, есть ли какие-то документы, регламентирующие данные вопросы?

Заранее благодарен.

Существуют.
Например Bob Johnson ABAP Programming Standards and Guidelines. (рекомендую)
Регламенты бывают в каждой компании свои, а могут и отсутствовать совсем.

Можно воспользоваться транзакцией SLIN - (AВАР: расширенная проверка программ)

и еще здесь
http://sapforum.biz/index.php?PHPSESSID=85ba7a12fc40f3f34ec05c13f97f5de3&topic=174.0

Разумный вопрос поднят. Хуже нет, когда код, именование и структурирование его у некоторых самородков на проектах отличается от принятых за основу в коде вендора. Легче выкинуть сплошной неструктурированный поток сознания на 2000 строк, чем исправлять или разбираться в нем.
Имхо. Кнопка Pretty Printer + namespace convention (н-р, _DTE_ , _DOM_ , _STR_ .. в именах объектов словаря ) по аналогии с применяемым SAP в Вашем модуле. Имена параметров - I.. (import), E.. (export), и т.д. G - глобальное определение переменной, L - локальное.
Понятное дело, необходимо помнить о требованиях SAP, как н-р ZBAPI_.
Бейте большие куски кода на небольшие (по смыслу) функции/подпрограммы; хорошо дисциплинируют так же классы (интерфейсы).
И комментарии лишними не будут - Ваш код будут читать не роботы, да и самим через пару лет пригодится. Удачи!

Спасибо за внимание к теме.
Лично я уже привык придерживаться стандартов по именованию и форматированию текста, в том числе, всегда старался использовать структурную печать.
Однако, вопрос несколько в другом.
Меня больше заинтересовало наличие стандартов именно по форматированию кода, отступам и пр.
Так, к примеру, в селектах, насколько мне известно, предпочтительно такое представление условий:



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

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

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

Дежа вю?
Старый пост
Еще более старый пост

NASA'вский стандарт - это конечно хорошо, но в каждой компании должна быть разработана своя документация по правилам ведения разработок. Если её нет, то не имеет смысла придерживаться чужих правил, разработанных с учетом чужих требований к коду. Тем более, что трудно обязать всех разработчиков в таких условиях соблюдать стандарт, а без этого ничего все-равно не выйдет. Так-что пишите так как вам нравиться, тем более, что в этом случае ваша ценность как сотрудника будет выше (вас труднее будет уволить-сократить).
P.S. Комменты тоже в программах не пишите, а рабочий код маскируйте всяким мусором, который реально не влияет на выполнение программы, используйте побольше вызовов подпрограмм, методов, вообще таким грязным трюкам хорошо можно поучиться у саперов, берите в качестве примера для подражания любой стандартный большой отчет (например J_3RMOBVED).

Да, действительно, в каждой компании должна быть разработана своя документация, чтобы пресекать на корню то что написал Shade...
Если таковой документации нет, то писать код надо как можно аккуратнее и понятнее, с обилием комментариев и тд(см пост V®), по крайней мере стремится к этому. Ваш код, скорее всего, будут смотреть и редактировать Ваши коллеги, да и самим потом будет проще.
На счет

Бред.

Да-да будь хорошим работником, прикрой своим энтузиазмом и самодисциплиной безалаберность руководства. Теперь задумайтесь, зачем нужны стандарты в программировании? Затем, чтобы код не зависел от особенностей письма отдельного сотрудника. Затем чтобы этого отдельного сотрудника можно было легко заменить любым другим, предварительно ознакомив со этим стандартом. С другой стороны, если какой нибудь программист напишет какой нибудь очень важный код в "оригинальной манере", так что кроме него никто быстро в программе не разберется, то такого сотрудника хрен уволишь. Отсюдо легко заметить, что в стандарте заинтересованно руководство, а не работники, и сразу возникает вопрос: зачем работнику самому исполнять работу руководства облегчая при этом сокращение/увольнение себя любимого?

Да ладно... не так уж сильно влияет стиль оформления кода на восприятие, ну на 5 минут дольше разбираться...

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

5 минут говорите?
Ну пример стандартных САПовских программ показывает, что можно и гораздо больше времени потратить...

Стандарт хорош именно тогда, когда он спускается сверху, в сочетании с контролем качества кода это дает не только формализацию методов выполнения задач, но и инструмент оценки качества выполненной работы. Руководитель заинтересован в стандарте, если он не разработан, то это характеризует его не с лучшей стороны.
Когда-же инициатива идет снизу, то стандарт бессмыслененн, вкусы у всех разные, все будут писать в меру своих предпочтений и понимания. Представьте себе аналогию, что каждый житель РФ сам себе выдумает законы и будет их придерживаться, ничего кроме бардака здесь не выйдет.
При этом компенсируя косяки руководства своим рвением вы ещё нарушаете обратную причинно-следственную связь (принял неправильное решение - неоптимально выполнил работу - получил по шапке), вследствие чего руководство не скорректирует свое поведение, ни будеет заменено на более профессиональное.

То есть основная задача руководства - уволить всех?
Вообще-то в первую очередь увольняют тех, кто не справляется с работой (и не выполняет требования к оформлению работы в том числе), а не тех, кто с ней хорошо справляется