Skip to Content

Are 30 characters enough to make your code better?

In my opinion – yes, significantly.

Rewind. Let’s start from the beginning.

After getting the information about the new edition of M. Fowler’s “Refactoring” ( I started to think about refactoring process in the ABAP world and which technique I would select as a winner in an almost never-ending run in making your code cleaner and more readable.

I got back in time when I was entering the mysterious, a little bit closed and unreachable ABAP environment. I was a Java programmer, lucky enough to work in a company with an SAP system. In Java, I was coding mostly Swing apps. I felt good to name my variables like “mainWindowHeader” or “currentTime” or “username”. I was reading other’s code and I was understanding it.

Then, when I was entering the ABAP world, I felt like being suddenly parachuted into a country, where people speak few words in English, but the rest of their words is very hard to understand, not to mention pronunciation. My cognitive shock was big – from object-oriented Java constructs to report’s hell with plenty of includes, function modules, subroutine pools, global variables (and a lot of pseudo object-orientation, but this is the topic for another story). The very first problems to solve in my work were supporting tasks and corrections in some reports/function modules.

What was common to every piece of code I’ve seen was variables “chg_kstsn_uzeit”, “howd_maknr”, “cruname”, “br_pernr”, “kur_btrtl”, “old_belnr”, “l_dbblg” – does it make sense to you?

If yes – great, you’re an experienced developer in SAP modules. But if you stop thinking about your experience in SAP, is it really the best you can to name things? And – what is the most important – why still so much ABAP code is written with variables named like entered by my cat having fun stepping on the keyboard?


The first answer – maybe the authors were like me, a young programmer used to see a lot of that code, thinking that this is how the stuff works in this very strange ABAP world. Yes, I got used to such style of coding, I started to do it in the same way and it took me a while to see and understand the difference. Of course, I read a lot of books, but – as a rookie – I was concentrated on digging into the guts of the language, not the style and readability. Maybe I used to think, that complicated code is so goooood and advanced and pro but I’m too ashamed to admit it today…[veil of silence]

Getting back to our BRTFL, ADASE, XCDER and other – they mostly come from the data dictionary where we have plenty of database tables with all these 5 letter long column names. They are then used in structures and other DDIC artifacts, finally ending in the code in various flavors – prefixed, as a part of the variable name and so on. Is it OK?

In my opinion – no. It’s something that really hurt. You encode your code variables using another “language” which you (currently) understand.

Consider the example:

IF ( p0001-btrtl = 'AZW3' AND p0001-abkrs = 'ZW').
  schedule_payment( v_pernr ).

  IF ( vcr_uzeit > '160000' ).
    schedule_report( v_gsber ).

And now this:

IF ( personnel_subarea = 'AZW3' AND payroll_area = 'ZW').
  schedule_payment( personnel_number ).

  IF ( reported_time > '160000' ).
    schedule_report( business_area ).

Which one immediately tell you a story? Which one doesn’t need any, even minimal mental “decoding” of the variables? Which one is more readable by ANY developer?

And when you go even further in refactoring, adding more meaningful constants and small changes…

IF ( personnel_subarea = security_employees AND payroll_area = weekly_paid ).
  schedule_payment_for( selected_personnel_number ).

  IF ( reported_time < reporting_final_time ).
    schedule_payment_report_for( selected_business_area ).

…you can read it as a natural language.

Use meaningful, intention-revealing, pronounceable and searchable names without mental mappings and shortcuts. I won’t be covering the techniques and I’m doing it intentionally – if you haven’t read any book about clean code just go ahead for one – I really like “Clean Code” by Robert C.Martin. I treat such books about refactoring and coding techniques as a guide, keep them close and use them very often when I’m in doubt.

Now, there might be voices:

Hey, stop, I do my development in a very specific environment! Maybe the names are not so readable, but they are from the problem domain! They are from the solution domain! We, ABAPers, know the stuff and this actually speeds up the things, we use commonly known language!

Well, in my opinion, this is an old-fashioned approach. From my personal perspective, it worked some years ago but it doesn’t fit now. Why?

Once again I’ll get back in time. When I was starting my IT journey there were people, the majority of ABAPers I know has been working for the same company, year by year developing the code in modules they know. It was really a centralized work; the code was often in hands of the same people year by year. But things have changed – there is more and more work and still not so many people to get it done. Outsourcing started to play a big role. We change work more often, companies want to have all those shining, cutting-edge features and the only constant thing is change. We switch the context very often. Even if I’m specialized in SAP HCM during my “support” path of career I was fixing the code in MM, CO, FI, TM, PS and several others I can’t recall now. And of course the whole line of HR – PA, PM, OM, PD, PT, PY etc. and SAP Gateway. I don’t have to be an expert in the specific module to get my work done with the assistance of a consultant and when someone has asked me to change the ALV headers in some report or check if the algorithm for a cost area is making the right approximation, unclear names are really not helping.

Next thing related to our memory – even if I’m good at my module now, I can be assigned to other tasks and really forget some of the stuff. After 2 years I could not remember what was that GBRTL. Not to mention that SAP tables can be really huge and memorize all 34 fields seems odd. Multiply this by the number of tables in the modules and you will get a pretty huge number of fields.

Several years ago I had a talk with a developer about the code he wrote and we were working on; during this talk, he explained me his code and what was noticeable – he was using names from the dictionary because he wanted to quickly recognize (due his knowledge in the specific area) that this text field is, for example, 30 characters long. It was easier for him to process them later for an ALV list. Yes, It might work for you, but still, the name of the variable is not for the type. Its type is in the data or type declaration. If you remember all types and its specifications, then your IDE will tell you that this is your favorite BETRG or other:

Not to mention, that if you follow good techniques, the variables are so close to their usage that you can glance at the declaration easily (reports with 22 INCLUDES, 89 global variables is the topic for another story).

Now, do you see what is common in the above arguments? YOU – as a reference for the code. You as an expert, you as a programmer, you as the owner of the code. But now WE should be the most important. We as a team, we as collaborators, we as colleagues who left our code for others. We have now ABAP in Eclipse, we can store it using Git, we do code reviews, continuous integration, unit testing. Of course, team-oriented and clean code existed even when I was playing on my Amiga, but I think that things have significantly changed last 10-15 years – towards sharing parts of the code with various intentions, even in the ABAP world (which sometimes seems to me a little bit behind the concepts and ideas circulating in the other programming language universes).

So, use wisely your 30 characters – it is a rather small number, having in mind that ABAP is case-insensitive and you have to use a separator for different words. Think about the essence of your variable, its core, its identity. These 30 characters could really make your code better, refactor them always if you think it might help to understand the code. ABAP is a really powerful language for declaring things and actually it might be a good topic for another article – hints about using its features for cleaner code.

Finally – why variable names are number on my list for readable ABAP? Frankly speaking, they are the most important thing for other languages I use. But in ABAP they are extremely important – you can write a quite big piece of software using REPORT and its events, structured with basic subroutines and reusing few existing function modules and classes, because the language offers a lot of statements for processing data. Variable names are really important for ease of understanding what the heck this code is doing. Of course, other names (methods, classes, functions and so on) are also important, but I wanted to pick my very first on the list.

In this busy, advanced times, it is vital to make things simpler. I believe that any colleague who has to analyze your masterpiece algorithm, correct it or review, will definitely appreciate readable language other than MTTAS, QWDER, G_WGVBH and other ZXCSDQEW.



You must be Logged on to comment or reply to a post.
  • good point and both refactoring and clean code books look interesting. Name of the parameters are very important but personally i prefer to create a structure for them and collect parameters inside the structure (for existing line and reference parameter values).  If i see a stand alone variable named "personal_subarea" and "payroll_area" , it drives me crazy as well :). it can also be like this;

    IF ( ls_line-pers_subarea = ls_param-sec_emp AND ls_line-pay_area = ls_param-weekly_paid ).

    Variable name is one thing, same approach should be applicable for method names as well.

    • Thanks for your comment 🙂

      Yes, structures are very valuable. I'm also using them to overcome the limit of 30 characters - the name of the structure is can serve as a meaningful part of the whole. I even introduce structured type just to move there one variable - if the additional 30 characters can improve code readability.

      Report parameters are a good example - 8 characters available :/ Instead of p_abcde or so_zxcvb I prefer moving them to ls_report_input-order_number at the very beginning.

      Kind Regards,


    • Sorry to disagree, but that dropped the readability right down again. I felt the need to answer, because to me it hilights how prefixes get in the way. Compare Jacek's version and yours side by side:

      IF ( ls_line-pers_subarea = ls_param-sec_emp AND ls_line-pay_area = ls_param-weekly_paid ).
      IF ( personnel_subarea = security_employees AND payroll_area = weekly_paid ).

      To me there's no contest.

      That is to say, I agree with the basic idea of grouping, but I'd put these into a global interface:

      IF ( relation-personnel_subarea = zif_personnel_const=>subarea-security_employees AND 
           relation-payroll_area      = zif_payroll_const=>area-weekly_paid ).

      Technically it's also possible to change the zif_ prefix, but most people don't like it. I think it would be useful to semantically describe the interface as a pure constant reference.

      IF ( relation-personnel_subarea = zconst_personnel=>subarea-security_employees AND 
           relation-payroll_area      = zconst_payroll=>area-weekly_paid ).
      • Gah... infantile platform won't let me edit my post. I realised P0001 is not relationships, that's 1001. So "relation" is wrong, it's org assignment.


      • Sorry to disagree! (i like it when people disagree with me ) That approach is called constant interface pattern and totally not suggested to implement. I am against to use interfaces just for global constants. It is not serving the purpose of an interface. Yes of course we can have global variables inside interface but it should not be just for our hardcoded global variables.   It is better all come from a ztable like zparam or whatever the name is.


        IF ( relation-personnel_subarea = zconst_personnel=>subarea-security_employees AND 
             relation-payroll_area      = zconst_payroll=>area-weekly_paid ).

        should be this;

        datA(ls_payrol) = lt_param[ 'payroll_area' ].
        datA(ls_pers) = lt_param[ 'personel_subarea' ].
        IF ( relation-personnel_subarea = ls_pers-security_employees AND 
             relation-payroll_area      = ls_payrol-weekly_paid ).


        • I like a good discussion too 🙂

          ABAP is different to Java. As far as I know, the kind of static access we can do in ABAP is not possible without implementation of sorts, which creates its own set of problems.

          In ABAP we used TYPE POOLS for storing constants, but they are obsolete and instead the ABAP documentation recommends a class/interface based approach.

          Regarding class vs interface, they are semantically exactly the same. I am open to correction, but as far as I remember one small difference is that classes are loaded into memory at runtime, whereas an un-implemented interface is is evaluated at compile-time. So for performance reasons I prefer interfaces.

          One point where I think we agree is that I believe there should be a clear separation between classes/interfaces used as constant repository and classes/interfaces. i.e. an interface used for constants should not contain any methods. And for this reason I like the concept of naming them zconst_ instead of zif_ in order to make that absolutely clear.

          In short: By ABAP's ability to use interfaces as a pure compile-time access, and not mixing 'constants usage' and 'programming usage', we are avoiding the pitfalls that the pattern creates in other languages.

          Lastly, I also find it easier to read and use. A table must be filled somewhere - at which point we are almost back to reading customising in the DB. With classes/interfaces, I can put my cursor on any of the elements and press F2 to quickly see more details and navigate around all available constants.

          • Yes Mike i agree there should be a clear separation for classes and interfaces and also it depends on the whole architecture in the backend. Comparing to type pools of course i prefer interfaces at least more tidy, more readable and more fashionable. Usage of pure interface or table, i believe depends on the environment. For ECC which is more stable and less likely to change environments, usage of interfaces might be a better solution but for planning environments (i.e BPC ), which i am mainly working on, scenarios and assumptions are changing more frequently. In that case table solution is really a life saver for me and still i have constant variables in my classes / interfaces of course.



  • Our ABAP was running whole industries when RAM was measured in kilobytes and your Java was not even born. Get off my lawn! Kids these days... 🙂

    This is a great blog, and "parachuted into a country" made me chuckle. I totally get it how ABAP can sound like an equivalent of Idiocracy to someone coming from later generation languages and I appreciate your perspective.

    You are not wrong. We can do better job and use more descriptive names. (Stuff like c_zs01 VALUE 'ZS01' ought to be illegal.) But we might have different opinions on what "descriptive" means exactly.

    See, when you program in Java, I'm guessing you have a technical specification and there is no disagreement or misunderstanding on what exactly "OrderType" or some other field means. In the SAP world, MATNR is MATNR, everyone knows that. But the business users stubbornly continue using words like "product code", "part number", SKU, etc. Let's say I name a variable part_number because that's what it says in the spec. Later a consultant has to work with my code. The spec might not even exist anymore and the consultant worked at another company where MATNR is called "product code". Would my name be really helpful to them?

    And what if there is a team that speaks different languages? Today I'm working on the code in the US, tomorrow it could be someone in Germany or Russia or India. Of course, English is considered a common language but SAP dictionary names are like our Esperanto. 🙂 For one, I'm thankful that the SAP's own developers at least used the variable names everyone can understand when they wrote comments in German and named routines like "pruefen" or "abgesetzen".

    Finally, SELECT CORRESPONDING doesn't give a hoot about "clean code" and won't work with different names. And it can be quite helpful.

    ABAP is not Java. And it's a not a bad thing. We can still take advantage of the ancient functionality and use more descriptive names where it's advantageous. We can have the best of both worlds. Old is not always bad, just like new is not always best.

    P.S. There was a whole big discussion on the variable names few years ago on SCN. It was mostly about Hungarian notation but the comments were all over the place:

    • Many thanks for your comment ? I understand your standpoint because I was thinking the same and now I’m on the opposite side. Your mentioned MATNR is not a good example, because ABAP programmers very, very often tend to use a whole range of those 5-letters long bastards ? And they assume everyone knows everything in the same way they know – including 2721 fields like WLBGT, BTREW and others.

      I prefer to review and correct “naturally” readable code, I will see that “product_code” has MATNR type. I can really get into any code much easier if the names are clear.

      Of course, give me 3 programmers and there will be 4 opinions :D, and all valid to some extent…



      • Personally, I don’t have a very strong view on this either way, to be honest. If someone wants to use longer, descriptive names then godspeed. If someone uses names like lv_matnr then I have no problem with that either. It’s just not something I feel very passionate about. Don’t get me started on itab_temp though. ?

        By the way, if you don't like lv_matnr definitely do NOT visit this thread. 🙂


      • Yes , yes, yes!

        ABAP as a language isn't that bad (although heaven help me why you'd want to build in SAP CP with it! - Different blog) but it is the need for developer to have an instrinsic understanding of so many archaic and domain specific codes that make it difficult to throw a new developer into this space. Hence costly and stagnant.

        Do not get me started on Hungarian notation!?





    • Re. which descriptive name, I either look up how SAP calls it in the BAPIs and use that. It's consistent, nobody can argue with it. Failing that, STERM is always a good reference source.

      As to CORRESPONDING, these days we have

      orders = CORRESPONDING #( vbak_tab MAPPING order_number = vbeln
                                                 order_type   = vbtyp ).
      • Well, WE don't have this. 🙁 At least not yet.

        Also VBTYP is "SD document category", AUART is document type. Gets me every time. That's exactly why I just stick with the technical names for most part. 🙂

        • Ah, pre-7.4, forgot ?

          It was just an example, I haven’t worked with SD in years, didn’t even know if I had the cat-encoded fieldname right (No, don’t ask why on earth I chose that as my sample…).

  • /
  • Nice post! Like Jelena Perfiljeva I am ambivalent, although I would (perhaps until this post) have come down on the side of the shorter, five-character names, for two reasons: happy memories, and readability.

    Happy memories - this is not a good reason, but it is a valid one for me; it reminds me of the happy times (times are still happy, btw!) when I was just discovering SAP and figuring out what everything was (I realised soon that figuring out *everything* was going to be futile). I like the memories of what the five-character names conjure up. Heck, even my online moniker "qmacro" is an homage to the five-character Q-macros of the SAP R/2 assembler infrastructure of yesteryear!

    On readability - it's not the readability that you talk about above, but the fact that I prefer short sentences and narrow margins, in the same way that other people do so that newspapers print in columns rather than right across the broadsheet. It's a hurdle to get over to understand the five-character names, but it makes (for me) reading of code much faster. I detest long field names.

    There. I said it 🙂

    • Thanks DJ!

      I was about to post something along the lines of "short is beautiful" as well but you beat me to it! Like you, I really like coding which I can actually take in with one glance without having to trace a looooong line of code spilling way over the 72 characters "limit".

      But, I admit that I have one advantage when it comes to the very short "historical" SAP-table- and fieldnames: I'm German, so can actually quickly "see" - at least in most cases - what they mean and are meant to abbreviate. This obviously makes them look a lot less like gibberish or haphazardly thrown together letter salad ?.




  • I completely get your point of this blog, but I am also old enough to understand WHY some of these old/bad habits do not die. When I first got into SAP and the ABAP world as a VB/C++ developer, it was about the time a lot of the old mainframe folks from the COBOL world were retooling over to SAP as well. Of course, even then, all the old timers loved to check each other with their tales of all the many obsolete languages and systems they learned and experienced over the years. Many of their previous habits found their way into the “ABAP programming standards” guides we all worked with back then (and some live on till this day!) because “hey, these are the old wise programmers, and what do a bunch of us young C++ whipper snappers know?!!”” haha

    So a BIG part of namings and such….as I recall….was yes, to keep everything short and concise as possible….BUT this was because “those old dudes” were very sensitive (fear driven? haha) to not only the memory consumption of variables themselves (don’t use too many!)…but to the very file size of your source code (cause you know……wayyyyy back when, storage and memory were VERY expensive both in performance and real world costs). So THAT is why a lot of that naming nonsense you railed on came to be (and lives on)………there once was a time where every little byte really did matter!!!!

    And yes, times have changed and things  have evolved…..but honestly, who really wants to enjoy all the “fun” of going back and overhauling their development standards guide? haha I still go onto client sites where their ABAP standards guides haven’t even been updated to include anything ABAP OO  or even webdynpro!


  • Hello Jacek,

    allow me to disagree with you.

    Variable naming is part of the programming style and does not help me make better code.

    Case in point.

    IF ( personnel_subarea = security_employees AND payroll_area = weekly_paid ).
      schedule_payment_for( selected_personnel_number ).
      IF ( reported_time < reporting_final_time ).
        schedule_payment_report_for( selected_business_area ).

    How do you create a test for such a code?  Too difficult? then change it to something easier to test. I would try to change my code to look like

    METHOD shedule_payment.
      CHECK valid_area( area = p0001 ).
      schedule_payment_for( personel_number = selected_personnel_number ).
      schedule_payment_report_for( business_area = selected_business_area
                                   reported_time = reported_time ).

    My point is, I first think of the target structure of the code that is easy to reason about, than mold your logic into this form.

    Of course the code also reflect my limitation in understanding of the problem. But the next developer can get rid of my faulty logic because she understands it and knows better.

    The variable names? I use hungarian, so I do not need to think twice about them.

    Respect the style of your colleagues or have lengthy discussions, I don't see benefits. Keep a consistent style in a large code base and the coworker will adapt to your style when they work with your code, just like you do with theirs.

    My priority is to make the methods short, shorter than that.




      METHOD shedule_payment.
        CHECK valid_area( i_a = p0001 ).
        schedule_payment_for( i_pn = s_pn ).
        schedule_payment_report_for( b_a = s_b_a
                                     r_t = r_t ).

      Is worse code than what you posted. Ergo "Variable naming is part of the programming style and does not help me make better code." is incorrect.

      Readable variables make your code more readable (And more readily fixable at 3am on a Sunday morning by a psychopath who knows where you live ), and that makes it better.

      Style is as important to good program as logical structure, efficiency etc.

      • Hello Matthew,

        Is worse code than what you posted.

        first define worse.

        There are differences in the way people think about design, construction, and testing .These alternative viewpoints tend to come up as a result of of someone saying I never (find a need to) use that pattern or I never tun into that smell.  understanding that others subscribe to a different philosophy helps us appreciate why they do things differently. (Meszaros, xUnit Test Patterns).

        Quality is in the eye of the beholder. I will follow Sandi Metz insight and suggest this metric for good code: the ultimate measure of code quality is how easy is it to change.

        I think even with the obfuscated variables names, your version is easier to change than the original version, because you have a scope (method) and a simpler sequence of activities. If I can correctly guess this code will schedule a payment and create a report, then I have enough information to create a unit test. I will move on to the great scheme of thing before coming back later and look at the details, if time permits.

        Having a really short method makes the variables less relevant. Changing the parameter names is a low risk refactoring. And if tests were in place, I would go on and change the parameters and variables to something meaningful.

        The variables are harder to read with the odd naming for the importing parameters but I see this topic as low priority (not in top 10) compared to having short methods, shorter than that.

        Note I would use database field name with prefixes and stop there, having achieved code that is easy to read in a context. I would only spend time discussing other names if the variables are global.

        As any individual style will evolve with exposure to different code bases, I think what help changeability is a consistent style over a code base.


          • Hello Florian,

            I am probably repeating myself:

            Code solves a problem in a domain. Domains with deep models have an ubiquitous language used by the domain experts. I think the focus is to write code that is read by domain experts.

            I guess we feel mastery of a language when can play with it and create something that we can call beautiful, e.g. prosa that nicely communicates an idea, describes an emotion or makes a point.

            Natural languages can be fuzzy, as a word with many consonances will evoke different feelings in each reader. OTOH, we want code to be more like a formal language that can be verified without ambiguity. If am not sure what a line of code is doing, or, what the author wanted to tell me with this code, then the code is probably wrong or I will probably make a mistake while using it.

            I see English as a great language for the Given-When-Then form of a BDD test scenario, but is not a desirable target for my code. I prefer established terms from the domain as they avoid a translation between specification and code.

            I assume SCN is biased, because contributors with excellent English skills will lean toward English as a specification language. However while modeling an application, we use abstractions that are only valid with the boundaries of our given domain. Those limits should be made explicit. i.e. they might require a conversion layer, with new vocabulary used at both side of the layer (cf. Eric Evans Domain Driven Design).

            TL;DR: In some contexts, english is worse/unreadable and P0001 is clearer for the abap-room.



  • Jacek,

    JAVA to ABAP should be easier especially from the OOPS concept.

    ABAP to JAVA....let's not even discuss that.That is not another Country but all together parchuting to a different Universe. 🙂

    Nice blog.


  • Hi,
    Thanks to Jacek for opening this topic. I'm working for 12 years as functional, analyst, architect for SAP. Of course I wrote lots of specs and debugged lots of programs in SAP. Developers can be free to use any variable in programming. It's really clear using lv_matnr or lv_pernr or lv_vertrag to everybody if you are a part of specific module. Guess you are trying to read Sheskepeare. You should be familier to literary world. If you are a part of Mathematic science world you can think what is all these mystical words.

    I want to focus on what we are looking as customer of developers. I will continue with Jacek sample.


    " We are checking personal sub area and payroll area to decide scheduling 
    " Weekly payments of security personal are being mailed to HR.
    IF ( p0001-btrtl = 'AZW3' AND p0001-abkrs = 'ZW').
    schedule_payment( v_pernr ).
    " If it's later than 1 day we are performing payment report
    IF ( vcr_uzeit > '160000' ).
    schedule_report( v_gsber ).

    I tried to give a sample of a clear comprehensible coding. Developers may use X,Y,Z as variable. But they should add "comment" to programming . You should not thing my codes are talking. Of course it's easy to read "if" "then" "else".

    If you are new programmer or old developer of that program or new functional of that module mostly problem is not reading of variables, the problem is why it's coded. There should be totaly a big paragraph starting part for description of this function or program. And of course some annotation sentences in specific parts of code.

      • I didn't missed any part of the blog. I'm saying you will learn "SAP world"language if you are trying to communicate with them. You are trying to change how communication becomes in this world. You shouldn't. It's almost %99 percent clear to any SAP consultant or developer. If I'm HR consultant i can clearly understand what it means personnel_subarea = "AZW3". But You say there should be a global definitions in coding. I say no. Programmer is totally free to write anything. It is not better writing English definitions in codings. Jacek wrote that he was JAVA developer and when he started SAP he didn't understand this language. Why because SAP has specific language like Turkish ,German, Mathematics, Physics etc.

        Talk this with a mathematician .They will laugh. Because they use square, pi etc. totally mathematic annotation. Can you say them don't use math specific annotation eg: a2+b2 = c2  you should write first_line2+second_line2=longest_side2 🙂

    • I will just expand on that a bit.

      If you need to add a comment


      function_02( v_vsbed)."Evaluate shipping conditions for express option

      then you could say

      evaluate_for_express( shipping_conditions ).

      You end up sounding like Yoda but nine times out of ten a comment is an indication the variable / method /form routine name is baldy named - so it has to be annotated wth a comment.

      If the abbreivations were indeed self-explantory then why would you need a comment? The more compact the code is then the easer it is to understand and thus maintain.

      Comments should be WHY something is happening. The code should say the HOW. If you say WHY you did it this way (because the obvious way did not work) then the next programmer might not conclude that you are an idiot and change it back to the obvious way and then get the problem you already had and solved. That's what comments are for.

      Why in English? Beacuse the keywords are in English. A mixture of English and German in code made life hard for programmers in both languages.

      Therefore my rule in life is to make code read as much like natural English as possible, given the constraints of ABAP.

      Cheersy Cheers


  • I love this post.  All the comments it has generated is great reading.   In ABAP I remember when I was just starting, a person in charge of Crystal reports wanted us to build out all of our code and/or Z tables with the actual names.   That lasted about 2 weeks.  It was just too hard.  (PDF, RAW, SKU, Part number, Material number and the list went on)  We also found move-corresponding no longer worked for us.

    Fast forward....   ABAP CDS  anyone?  Without looking at the view in Eclipse, it makes for an interesting thing to add to your code.   The "real" names are used.   PurchaseContract, Supplier, Document Currency.   And the list goes on.

    So I'm back and fourth on this one.  It's nice to have self documenting code when you go to write the functional/technical spec.   You know the one that is started but never finished until you are done.  (Done is relative by the way)  I like the 5 character fields as I know what a lot of them mean.  And I find it easier to read the code by using the shorter names.

    I remember getting sick of comparing 'X'.  I used to code lc_true, lc_false.   Now we have the ability  use abap_true and false so my code has changed just a bit.  OK a lot of my style has changed, but I do still use the five digit fields unless there is a good reason not to.  🙂  LOL  In other words I do  both depending on the project.

    • Thanks for your comment!

      For me CDS or rather Interface Views from VDM have brought the first revolutionary change (readable names to cover these ugly technical ones). The second one is Clean ABAP style published, with all rules like meaningful names, no encoding prefixes etc.