Skip to Content

Thought of writing the blog the share the most common issue after a SAP maintenance project is handed over or when new consultants come into the project. The first few days there are high level descriptions/discussions of what’s there in the landscape and what not. Then comes the hard part when bugs or tickets or incidents starts coming in. Then the effort taken often to understand the process is often painstaking due to lack of code comments or documentation(In code and as specifications) and usually ends up taking  more time compared to what might have been used if it was done in the first place 🙂

Little comments in the code if they are missing often don’t reap the benefits immediately but always help in the long run. The missing comments are like small amounts of C02 that eventually causes water levels to rise and thus flooding or temperature swings..(when you manager is chasing you solve an incident or an issue and you don’t have enough time to dig through the layers of custom code and hope that some documentation or comments would have helped)  and the effort to do it later is much more effort-intensive.

Now people might think what it has to do with say I create 1 Z-Report or 1-Function module or Just activate a BADI and write a small snippet of code. But in the long run artifacts or objects gets added over the years, remember business that use Z-process would not change often and keep doing even more customizations. I had the experience of working with such clients. They install SAP and then create Z-Transactions to fit in business requirement, 😕 might sound crazy and stubborn but the logic often given is I want my business to run my way not always the way what SAP says( suits them as they are one of the BIG 5 consulting firms 😀 ).

The other thing is now we get many versions of SAP modules and categories and often many scenarios and modules and processes and business practices are not always accounted for in standard SAP packages or often come later after SAP starts delivering it for such and industry. Such things are validated by the various solutions SAP has delivered from time to time. Like access of SAP clients shifted from Desktop client in its early years to web-based and now moving to cloud based to many new modules introduced over years to get into various industry segments.

Now how can small comments help in the log run..

Well the small comment that you write and may be leave the project will always help the other consultant coming in and trying to do some changes or add on code or comment out logic. I know the other aspect is people will say what about requirements and design documents. Well they are often done in a bare minimum way and often its not there. Another scenario is often say an age old documentation of a report of Module pool screens exist but the programs might have changed several times over years and the initial logic parts might have changed or many new features might have been added and that’s not there in the documents. Such things often take more time as the developer has to understand the feature and then do any further changes.

The other most common scenario is copying BAPI or Standard FM’s and then not doing any documentation. Specially with lots of flag fields and generic structures. If large code blocks and nested Z-objects are there they often raise the efforts to understand the code( I remember the days without the new editor and debugger 🙁 ) .

Imagine how bad the demo programs will be provided by SAP, had they missed out on the comments 🙂 I am sure few runs and debug would be required to know what’s happening.

Often small comments and documentation set the pitch for quick understanding improves code readability and thus improving maintainability. Remember when you clicked the documentation button and it said only available in DE 🙂 and then translated then via translation tools or sites in internet. 😀

With the future going OOPS. Its good to have class and methods commented and documented as they are complex objects and say a Z-class with Z-methods if not documented can be hard on people following up with changes or additions to the same. Basic comments or on use of class and methods will always help.

So small missing documentation or comments can make a simple custom development look apparently complex. If present and done on the time development or changes are done can save a lot of effort for future and help improve code readability and maintenance.

So, follow the rule of always commenting or documenting even though it looks useless its good in long run. So ending this blog with few links on documentation.



To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member

    Well, long time ago i had a collegue doing his stuff in assembler. Of course without any comments.

    So i’m forced him to comment his code to clearly state what he intends to do.

    After some days he came back very proud saying that he documented all his stuff.

    What i found looking at the code :

    LD A, 3

    was replaced by

    LD A, 3 ; load register A with 3

    I dont know if this is something to 😡 or 😆 or 😥

  2. Former Member

    Code added by SAP notes have interesting style of commenting.

    If note number is 1234567, these kind of comments can be seen in code.

    n_1234567  — single line change

    n_v_1234567 — begin of change

    n_^_1234566 — end of change

    The usage of v and ^ is same as carrots shown when selecting text in some applications, like Adobe Reader.

    1. Suhas Saha

      The usage of v and ^ is same as carrots shown when selecting text in some applications, like Adobe Reader.

      I think you meant carets & not carrots 😛

  3. Raquel Pereira da Cunha

    Nice blog Arindam.

    This is an issue that all developers face, it doesn’t matter the language. And even when we find comments, they some times don’t help. What seems obvious for who is coding may not be obvious for the next person who will maintain. And that is valid for SAP standard too. I use the standard codes to learn when documentation is missing (specially with new functionalities.. standard documentation doesn’t follow the same speed) and the internal documentation (comments) are not very common. It’s a little bit better nowadays, but many years ago they were rare, and when existed they were in German.



  4. Mauricio Cruz

    Hey Arindam, nice post.

    I have a strong view about code comments and technical documentation… I’m yet to a see a project with a technical documentation that really aid me in solving issues, or guessing what a particular code is doing – and I think some small practices can really help understanding those huge amount of crazy instructions.

    I know we have tons of discussions here on SCN about the topic, but your blog raised the issue once more, and inspired me to do my own. Thank you for that!

    Best Regards,


Leave a Reply