Это прописная истина, не думаю, что кто-то это будет оспаривать.

А вот с этим не соглашусь - кто мешает сотруднику донести до начальства прописную истину? Опять же повысить свой статус можно

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

особенно если комментарии на немецком

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

Имхо, дикорастущий разработчик проходит этапы (и я проходил тоже)
- кодинга в стиле старых отчетов - простыня на_как_можно_большее_число_строк
- структурирование, функциональное разбиение
- принятие правил оформления своего модуля, стремление к чистоте кода; наработка утилит
- объектное программирование, стремление к элегантности кода, стремление к использованию новых возможности ядра

Меня в свое время здорово дисциплинировала разработка Add-On'а. Когда пишешь в партнерском пространстве имен ( /.../ ), начинаешь думать о том, как потом клиентским программистам расширять продукт, работать с ним.

Защита методом написания дерьмокода, в конечном итоге, играет против. Прежде всего из-за ограничения собственного развития.
Это как в анекдоте - джинн, выбей мне один глаз, чтобы у соседа не стало обоих. Не проще ли стремиться к качеству и потом уйти на фриланс с хорошими ставками? Может и не стоит контора, в которой можно удержаться только дерьмокодом того, чтобы в ней работать?

Как выше было сказано корпоративные стандарты хороши когда контролируют их выполнение

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

Интересно гдето в этим действительно занимаются?

Стандарты, да, думаю есть во многих конторах, но их полный контроль вряд ли. Как себе это представить? Написана программа, затем отлажена, затем что? Какой то специальный человек проверяет код на оформление? Думаю что это не реально... Просто есть стандарт, если потом где-то вылезет программа с "неправильным" оформлением то автора заставят писать например объяснительную, несколько объяснительных и увольнение по не соответствию должности...

to V®

ООП и структурирование - это конечно хорошо, но это повышает требования к собственно организации разработок. В условиях организационного бардака, неопределенности стратегии развития и постоянно меняющейся среды (а САП любит взбрыкивать и пересматривать) востребованность такого подхода в программировании невелика. ИНыми словами любая методика хороша к месту, повсеместное бездумное применение не есть хорошо. Тем более, что у ООП кроме плюсов есть ещё и минусы.

to Besa

В идеале должен быть человек занимающийся контролем кода. В том-же R3 есть Код-инспектор (тр SCID) для этого. По идее этим мог-бы заниматься руководитель АБАПЕРов, иным словом непосредственный начальник программиста.

Есть такая отличная книга "Совершенный код" за авторством С. Макконнелла. Подробно описываются подходы к конструированию программ. В том числе рассматриваются и разные варианты комментирования/структурирования. А так же и проверок кода. Автор рассматривает все на примере 3-ех языков: C, Java, VisualBasic. Впрочем, имхо, все легко экстраполируется на ABAP.
В частности, то что касается проверки кода: есть несколько подходов. Есть вариант с парным программированием. Есть вариант с инспекцией кода. Как раз в книге и говорится, что стандарт программирования внутри конторы должен быть составлен коллективно, а вот его поддержание - должно идти сверху.
Так что всем интересующимся - рекомендую.

Извините, Shade, но я не понимаю Вас...



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

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

И еще - Вы, наверное, работаете на старом модуле, где полно немецкого дерьмокода времен когда мамонты ходили по земле. Попробуйте как-нибудь поработать в одном из новых, молодых модулей, увидите разницу.

То есть вы видите в объектно-ориентированном программировании только плюсы, а минусов не замечаете?

Вы взяли из моих ответов одну фразу и начинаете холивар. Пишите так, как Вам нравится, мне до этого никакого дела нет Удачи!

Если честно, то даже и в мыслях не было чего-то там начинать. Просто хотелось более развернутой аргументации, но на нет и суда нет.

Нашел такую книжечку "UM ABAP Development Standards"
http://olemiss.edu/projects/sap/UM_ABAP_Development_Standards.pdf

Интересная книжка...
"The University of Mississippi | Confidential"

Когда я была Team Lead, то в мои обязанности, среди прочего, входила проверка практически всего ABAP кода, особенно написаного заезжими консультантами. Стандарты у нас, правда, были не слишком строгие (например, не придирались к названиям переменных) как раз по причине того, что они не были навязаны, а были предложены самими разработчиками и утверждены "наверху". Комментировать требовалось только какие-то сложные куски или какой-нибудь необычный код.

Проверка обычно проходила перед релизом транспорта из DEV, но за некоторыми гавриками приходилось следить по ходу дела и направлять их, а за некоторых, наоборот, я могла поручиться, практически не глядя. С full-time коллегами иногда делали т.н. "peer review", но они все, в принципе, писали нормально, как для себя. Таких жлобов, которые хотят считаться особо "ценными", как тут обрисовали, у нас, к счастью, не было.

P.S. Знаю, что в некоторых конторах есть обязательное требование, что Extended Check должен выйти "чистым".