Skip to Content
Technical Articles

Todo Based Coding in ABAP

Today, I would like to demonstrate a very simple but effective programming habit that I use in ABAP development: “TODO based coding”.

The idea is to plant TODO comments into the code (typically among multiple programs / classes) before actually starting to write / modify code. That enables us a few things:

  • Planning before coding
  • Simplifying large refactoring tasks
  • Figuring any semantic / functional gaps before modifying the code
  • Eliminating the risk of forgetting things
  • New programmers can take over incomplete programs

However, in order to make this technique effective, we need to make the compiler / IDE warn us if there are TODO’s left in the compiled code. Otherwise, incomplete code might go to production.

Looking at some other platforms;

  • Pycharm (Python IDE) shows #TODO comments as a separate list in the IDE
  • XCode (Swift IDE) evaluates #warning commands as compiler warnings and shows them every time you compile the code

As far as I know, ABAP lacks such a feature. The closest thing that I know is the task list feature of Eclipse, but they are stored in the local machine; so a new programmer doesn’t see them at all.

My simple but effective solution is to use a harmless fake pragma: ##TODO.

SAP doesn’t recognize this pragma, so every time I check or activate a code containing ##TODO , SAP will show a warning. Eclipse or SE80, works in both.

Here is how a typical todo looks like:

##TODO.
" Complete ZCL_CLASS1=>METHOD1 first
" call METHOD1 here
" ensure that the returned value is OK
" otherwise, raise an exception

Me & some fellow ABAP programmers are using this technique since a while, and we are happy with the results.

This approach can also be used when the architect and programmer are different people. The architect can create all the programs, classes, critical methods, interfaces, etc and fill them with ##TODO comments. After that, programmers can step in and start coding; clearing the architectural ##TODO ‘s.

You can also get creative and invent your own fake pragmas; such as: ##TODO_TICKET_123 or ##TODO_PRIO_2 .

I hope that this approach will benefit other fellow developers as well.

15 Comments
You must be Logged on to comment or reply to a post.
  • I use ##TODO too after having seen the idea some time ago in some SCN article.

    Hopefully SAP will never create the TODO pragma because then the warnings will disappear.

    We actually have a simple custom ATC check to find these and read an optional comment after the pragma (for example ##TODO. ” Comment). Unfortunately dynamic elements (like the comment) only get shown as “…” in the ATC result list, so not quite the TODO-list other IDEs have in other languages.

  • Thank you! I really like it.

    So far I used regular todo-comments and source scanner (rpr_abap_source_scan) to generate some kind of work list, but this approach in combination with ATC/SCI looks really good. I’ll definitely give it a try.

  • I like the fake pragma idea, will definitely use that. In some projects we have custom ATC checks to scan for todo in comments, but at sites where ATC itself is still a vague todo / #onefineday this is a really quick and easy alternative.

    However in many cases it can be more beneficial to write a unit test instead. There is the XP theory that one should write a unit test right before or after you write the functionality it tests. But if you have a design in your head right now, a unit test is a good way to document it. The bonus is you’re already part way there when you come back to it later. Just mark it as a tolerable failure so your tests still pass.

    METHOD method1_result_is_valid. 
      data(val) = cut->method1( ).
      cl_abap_unit_assert=>not_initial( 
          act   = val 
          level = if_aunit_constants=>tolerable ).
    ENDMETHOD.

    When the work is eventually done, just remove the level parameter to turn it into a real error. If needed, add the relevant expected value or other tests.

  • I preferred another approach: I often use a class ZCL_TODO with some methods stating similar to yours:

    • URGENT
    • NICE_TO_HAVE
    • PERFORMANCE
    • QUESTION

    The advantages to this approach are the following:

    1: You can define parameters so that you can describe the todo task:

    zcl_todo=>performance( what = 'check if join might be faster' who = 'John' ).
    zcl_todo=>urgent( 'wrong field used! should be XXX' ).

    2: If you run a cross-reference on the class or methods, you get a nice list with what to do. Yes, CI also does it but I find a cross reference more intuitive.

     

    The disadvantage to pragmas: even if the class methods are empty, you have real code. Pragmas might be less “dangerous”. Maybe using pragmas is better for use in eclipse.

    • I have used Eclipse tasks, and they work pretty nicely. The one advantage over the Pragma is that the list continues to be in front of you even if you have closed the source page in Eclipse. The disadvantage is that unless you set up a server, the list is only yours and can’t be shared by other developers.

  • I use the approach Lars mentioned above and pretty happy with it.

    Just placing Keywords into comments and find these again with my own checks. So I’m absolutely clean and can add markers for Code review, refactoring and whatever I want to.

    The idea of Peter I also have in my mind, but didn’t find time to dig deeper to get it up and running as it doesn’t is there for ABAP 🙂