Skip to Content
Technical Articles

ABAP_Freak->Show( ) Episode 2: Debating Hungarian Notation and Data References vs. Field Symbols

This morning I was joined by Rich Heilman as well as a lively crowd in the chat for the latest episode of the ABAP Freak Show. Today was a little bit of a different approach to the regular live stream.  Instead of a technology demo or live coding; today was all about debating two hotly contested topics in the ABAP development space:  Usage of Hungarian Notation and Data References vs. Field Symbols.  I don’t generally post a blog for each of the video or live stream sessions, but I thought I would make an exception this time in order to better share the related links and example source source code that we used in the video.

Of course if you missed the live stream, that’s no problem.  You can watch the replay at any time. Even if you couldn’t join the chat live; you can always add your thoughts to the comments on the video or here in this blog as well.

What would any healthy debate be without two opposing sides represented passionately. So in one corner we have Rich Heilman defending the usage of Hungarian Notation in ABAP. He makes the case that it allows looking at a glance to determine the type and scope of a variable and overall makes your code more readable without needing IDE features to assist. I took the opposite position that it clutters your code, that often the usage context can tell you as much about the object, the IDE can fill in the information more reliably, and that over time its too easy for naming to get out of sync with the reality.

And here was the simple ABAP class where we experimented with different usages with and without Hungarian Notation:

"! <p class="shorttext synchronized" lang="en">ABAP Class examples with and without Hungarian Notation</p>
CLASS zcl_hungarian_notation DEFINITION

     INTERFACES if_oo_adt_classrun.
     methods mu_export_flights
           !et_flights type /dmo/t_flight.
     methods get_flights
           !flights type /dmo/t_flight.
"! <p class="shorttext synchronized" lang="en">All Flights</p>
   DATA flights TYPE /dmo/t_flight.
"! <p class="shorttext synchronized" lang="en">All Flights</p>
   data git_flights TYPE /dmo/t_flight.


CLASS zcl_hungarian_notation IMPLEMENTATION.

  METHOD if_oo_adt_classrun~main.

    select * from /dmo/flight into table @flights.
    select * from /dmo/flight into table @git_flights.
    select * from @git_flights as FLIGHTS where carrier_id = 'AA' into table @data(lt_flights) .
    select * from @flights as FLIGHTS where carrier_id = 'AA' into table @data(flights_american).

    loop at lt_flights REFERENCE INTO data(lr_flight).
      if lr_flight->connection_id = '0017'.

    loop at flights_american REFERENCE INTO data(flight).
      if flight->connection_id = '0017'.

        et_flights = data(li_flights)

        flights = data(processed_flights)


  METHOD mu_export_flights.
    et_flights = git_flights.

  METHOD get_flights.
    flights = me->flights.


Of course we’d also recommend that everyone read up on the topic in the ABAP Clean Code Guidelines as well:

Next up was a debate that might not be as contentious as the usage of Hungarian Notation, but one equally interesting:  Data References vs. Field Symbols.  This actually came up as a topic during the recent ABAP Code Challenge and we thought it would be good to visit it in detail.

This too has been debated in the ABAP Clean Code Guidelines.  In fact the main part of the debate seems to be the impact on performance.

I personally much prefer the consistency and object oriented type approach that data references provide.  I was honestly a little surprised to read that there might be a performance drawback to data references considering they are the newer, more modern syntax.  So on the live stream we set out to test this ourselves.

Here is the test class:

"! <p class="shorttext synchronized" lang="en">Field-Symbol vs. Reference Performance Testing</p>
CLASS zcl_fs_ref_perf_testing DEFINITION

    INTERFACES if_oo_adt_classrun.
    DATA flights TYPE /dmo/t_flight.
    METHODS data_test.
    METHODS field_symbols_test.
    METHODS data_ref_test.

CLASS zcl_fs_ref_perf_testing IMPLEMENTATION.
  METHOD if_oo_adt_classrun~main.
    DO 1000 TIMES.
      SELECT * FROM /dmo/flight APPENDING TABLE @flights.

    data_test(  ).
    field_symbols_test( ).
    data_ref_test(  ).

  METHOD data_test.
    LOOP AT flights INTO DATA(flight).
      IF flight-carrier_id = `SQ`.
        flight-price += 35.
        modify table flights from flight.

  METHOD field_symbols_test.
    LOOP AT flights ASSIGNING FIELD-SYMBOL(<flight>).
      IF <flight>-carrier_id = `SQ`.
        <flight>-price += 35.

  METHOD data_ref_test.
    LOOP AT flights REFERENCE INTO DATA(flight).
      IF flight->carrier_id = `AA`.
        flight->price += 35.


And yes our testing did prove out the point that field-symbols are technically faster than data references; but the difference is so small that even in very large loop structures the difference probably isn’t all that noticeable. Still its good technical background to have on the topic.

Finally we did close out with one very special exception to the data references vs. field symbols debate: dynamically programming specifically with the assign component of structure approach.  Short of resulting to RTTI classes; I’m not aware of a real alternative to utilizing field symbols in this case. Feel free to offer suggestions if you have an alternative approach.  Therefore to every good guideline there remains valued exceptions.  Here is demo class to show the usage of the assign component syntax:

"! <p class="shorttext synchronized" lang="en">ABAP Inline Declaration</p>
CLASS zcl_inline_declare DEFINITION

    INTERFACES if_oo_adt_classrun.
    METHODS old_way IMPORTING out TYPE REF TO if_oo_adt_classrun_out.
    METHODS new_way IMPORTING out TYPE REF TO if_oo_adt_classrun_out.

CLASS zcl_inline_declare IMPLEMENTATION.

  METHOD if_oo_adt_classrun~main.
    old_way( out ).
    new_way( out ).

  METHOD old_way.
    DO 10 TIMES.
      SELECT * FROM /dmo/flight APPENDING TABLE @DATA(flights).
    FIELD-SYMBOLS: <line1> LIKE LINE OF flights,
                   <line>  LIKE LINE OF flights,
                   <comp>  TYPE any.
*    READ TABLE flights ASSIGNING <line1> INDEX 1.
    LOOP AT flights ASSIGNING <line>.
      DO 3 TIMES.
        ASSIGN COMPONENT sy-index OF STRUCTURE <line> TO <comp>.
        out->write( <comp> ).

  METHOD new_way.
    DO 10 TIMES.
      SELECT * FROM /dmo/flight APPENDING TABLE @DATA(flights).
*    READ TABLE flights REFERENCE INTO DATA(new_line1) INDEX 1.
    LOOP AT flights REFERENCE INTO DATA(new_line).
      DO 3 TIMES.
        ASSIGN COMPONENT sy-index OF STRUCTURE new_line->* TO FIELD-SYMBOL(<new_comp>).
        out->write( <new_comp> ).
You must be Logged on to comment or reply to a post.
  • I just had to watch the ABAP Freak show as I missed the live stream. But I want to share some of my experiences.

    I am a young developer and therefor way less experienced compared to many of you. But still ... I like some of the old concepts. I was "raised" in the hungarian notation style.


    Hungarian notation

    So let's first talk about the hungarian notation. As I just said, I still like it. I will add my arguments in the order you discussed it in the live stream.

    Length limitations

    Rich Heilman tried bringing this argument. ABAP has a limitation of 30 characters for variable and parameter names. With "flights" it still is pretty easy to see the plural here but try doing that if you have to use a lot of abreviations already (yes, some more complex business namings are a lot longer than that. It least in the financial world I am in). Maybe sometimes the plural can't be expressed enough at all.In that case the suffix "_tab" or "_table" is used. If you are short of characters anyway I prefer a single character in hungarion notation style.


    I totally agree that the prefix "l" for local variables could be omitted. But what about all the others?

    • "g" for globals: Especially in bad programmed reports I am happy to get another hint that I am dealing with globals. Yes, the outline is fine, but there is no outline that covers all inludes of a report.
    • "i" for importing: importing parameters are write protected. I want to know that before writing the assignment and the syntax checker telling me afterwards that I should not have done that.
    • "r" for returning: yes, that could be renamed to "result".
    • "e" for exporting: I probably shouldn't mess with them a lot in the code. But those are rarely used anyway in my coding.
    • "c" for constant: more or less the same as importing parameter --> write protected. Additionally there is a difference if I copy an importing parameter, local variable or constant to a target field.

    So to conclude that: I need g, i and c for sure. And so I am using them all for consistency.

    Type in second place

    I have to partially agree with Thomas that in most cases it is clear by the coding whether I am dealing with a table or structure.

    But there are some cases where I am happy to have them: When filling the return structure for an interface to an external system (e.g. excel sheets. Yes to be burned in hell but they exist a lot). And this forces me to use a very special non standardized date format (seen those already). I need to create a character field for that. I need to know which field is date and which is character.
    Or maybe even better: If I add 1 to a variable containing 20200430. Will the result be 20200431 (integer, amount, ...) or will it be 20200501 (date)? Yes I could look that up, but as Rich said: at least one more click even in ADT. In SE80 I might even have to leave my actual coding for that information.

    And I got another one for you: I can mark tables by plurals but how can I distinguish data references from data of elemtary tybe? I definitely need to know this!

    Code Completion

    Yes you might see all flight related variables without hungarian notation. When typing an if-statement that might be fine.
    Try typing a loop-statement. Then you might be happing by beginning with "lt_" and you get all variables that can be looped over. I forget the exact name way more often as I remember that I wanted to do something with flights.

    Wrong hungarian notation after refactoring

    I you really want hungarian notation and what it to be consistent try setting up ATC and configure it there. It gives you an error when the hungarian notation doesn't match. This could be even transport blocking.

    Importing Flag Example

    Yes a flag is no real datatype in ABAP, sadly enough. But I am not interested what it technically is but what I can or should do with it! Assigning a letter "A" to a flag is probably a bad idea. There had been a lot of discussions whether domain fixed values are flags but that is another story. In short: flags are characters with limited charset.


    I really like the idea of getting rid of misleading abreviations like hungarian notation. But as long as there are still some vital informations within them that I cannot get otherwise as quickly I will continue using hungarian notation.



    Field Symbols versus data references

    What amount of time was used to discuss on that topic ...

    Data references have one major advantage in my opinion: method parameters can be data references but they cannot be field symbols! So if I need to pass a big structure into a method and that method is called within a loop over a table of that structure --> take that data reference you have from the loop anyway and pass it to the method. All are working on the same data even across method boundaries. No more data copying.

    I have come to the following conclusion for me: If you don't need that minimal performance benefit and you don't have to do dynamic programming alyways use data refernces. On the other side that means if I use field symbols some crazy dynamic shit is about to follow.

    • I do not use Hungarian notation for indicating type of variables, but I do use prefixes exactly as you outline in your scope  section. In these cases, the use of the variable is being indicated, rather than its type.

    • Try typing a loop-statement. Then you might be happing by beginning with “lt_” and you get all variables that can be looped over.

      Hm, why would you have so many lt_'s in the first place? Even in the methods that run way over the suggested "3-5 statements" maximum, I've honestly never had such issue... Could this just be a sign that code should be broken into smaller "chunks"?

      • Honestly: yes it is. It is helpful when correcting older code but please read further.

        I also have to admit that the whole discussion here made me think. Currently I am not allowed to simply skip all rules and not use HN. We will try this in the next larger project so that one code unit stays consistent.


        One colleague gave me one important aspect to think about: If the code is readable by itself (aka good clean code) then HN can be easily skipped. If the code is written like 20 years ago and even that is done badly you might be happy having HN to understand at least a bit at first glance. So at least in my company the problem are the developers even struggling with OO and avoiding spaghetti-code. We will give non-HN a try anyway.

        • My take: abandoning HN going forward doesn't mean we're going to refactor all the old code. I think that's where most of the resistance is coming from.

          And there can be different approaches to refactoring some pieces of old code. For some time my position was the same as Bärbel Winkler mentioned: for readability's sake keep the same naming conventions as in the old code. But over time, I found that changing the existing code to remove HN can be more beneficial.

          There are, of course, exceptions. For example, a 2-line change in a large and complex program doesn't warrant refactoring Or in some cases, the existing code is so bad that an attempt to refactor might end up in much more work than anticipated. E.g. I tried to remove/rename some global variables in one program but it started to snowball into so many changes in multiple routines spread over multiple includes that I just had to drop the idea and roll back changes. And it's fine. As long as we at least stop using HN in the new code, it's already a step forward IMHO.

          Thank you!

  • At the risk of being ridiculed, I am also still a proponent of Hungarian Notation. Regarding some of the arguments Thomas made in the video, I would make the following counter arguments (with some overlap with what Michael said above):

    Context tells what you need to know about the variable!

    • This is only true up to a point. Consider Thomas's example of the SELECT into internal table flights. In that immediate context, it is clear that flights is a table, but what about later in the method? Even if I guess that flights is a table because it is plural, how do I know if flights is a parameter, global or local variable? But later on in the method, the name flights doesn't even necessarily accurately convey that it is a table. How do I know it's not an object or a data reference at a glance (as Rich liked to mention)? There could be usages of the variable where that is not clear without having to look elsewhere in the method for additional context.

    The IDE tells you everything you need to know about the variable!

    • Rich countered this by referencing SE38 (or even SE80), but since I am a huge proponent of ADT and think everyone should switch, I will not rely on that argument. Rather, at my company, we use a code review tool that requires text files of the code to be uploaded so that review comments can be added. Guess what? There's no element info to help in that tool... Or consider even the code snippets included in this blog. There's no element info to help me as I'm reading those, either. So even though I love the element info in ADT, it can't be relied on in all situations. In those cases, Hungarian Notation can provide a tangible benefit.
    • Also, using the element info still requires additional key strokes to position the cursor on the variable and hit F2 (or I have to always have the element info view open, which takes away from my development real estate).

    There are big advantages in code completion!

    • I'm with Michael on this one. Rarely do I need to use code completion to find all of the related variables for something (e.g. all objects, tables, structures, etc. related to flights). Rather, I usually know what type of variable I need, but I can't remember the name. So starting with "gt_" to get a list of all global tables is generally more useful to me.

    Hungarian Notation gets out of sync!

    • Sure, that can happen. But eliminating Hungarian Notation doesn't infallibly eliminate that risk, either.
    • Also, if "the IDE" is an argument in favor of eliminating Hungarian Notation, then surely "the IDE" (i.e. Ctrl+1 in ADT) can be a reason to say that renaming a variable when refactoring is quite easy.

    Having made those defenses of Hungarian Notation, I should add a couple other points:

    First, I definitely agree that an agreed upon naming convention is needed. I try not to get too granular in my abbreviations (e.g. I don't differentiate between elementary data type; strings, ints, chars, etc. all get a "v" as the second letter in my prefixes). While those added distinctions could be helpful, I find that they get too cumbersome to differentiate in meaningful ways.

    Second, I would never add Hungarian Notation to method names. I had honestly never seen that before watching this video. In my opinion method names should always start with verbs (or is_/has_/etc. for boolean methods).

    There's my 4 cents. Thanks for the video, I definitely enjoyed it! (Also enjoyed the discussion about data references vs. field symbols, though I don't have particular thoughts on that matter.)


    • Scott, please read Matthew's comment that is right below yours. (We don't get notified of other comments on the same blog, so I'm not sure you're aware of it.)

      Regarding this:

      How do I know it’s not an object or a data reference at a glance

      You know it from the syntax. If you see LOOP AT then what follows is usually an internal table name. I believe in case of reference syntax is slightly different and there are only few commands that are "multi-purpose".

      With all due respect, these types of arguments usually come from the people who have not really tried no-HN code. I've been doing it for a few years already. It was a bit weird at first (which is normal) but now to me the HN code is painful to look at.

      However, I do still use some prefixes, such as C_ for constants. I think in ABAP no-HN does not necessarily mean categorically no prefixes.Take a look at the DSAG guidelines on this.

      • Hi Jelena,

        As I noted in my comment, there are certainly times (I would even say many or most times) where the context makes clear the type, a loop being one of those obvious contexts. Where it’s less obvious at a glance is something like a method parameter. For instance, consider something like this:

        DATA(flights) = some_object->get_flights( ).

        I would assume that “flights” in this case probably contains information about multiple flights, but is that returned in a table, an object, a data reference? Again, remember that part of the context in which I find HN helpful is that my company uses a text-file based code review tool, so I don’t even always have the ADT element info readily available. So context and naming become that much more important.

        There’s also an assumption that all methods can be 3-5 lines, which is often just not true in real life (although I think Rich could certainly have refactored his method that was several hundred lines to break it into several smaller methods). Even a method that is 20 lines could have you searching for a few seconds for the context to determine a data type.

        I’m not completely opposed to the idea of eliminating HN, but I do think it’s fair to say that the anti-HN arguments are not valid 100% of the time. And in my current context, I still find tangible benefit from HN when it is used well. Of course, any naming convention can be terrible if it isn’t maintained or the names are unclear.

        Having said all that, I may start experimenting with coding without HN in some test classes and see how it goes. Maybe I’ll change my mind. ?


        • I would assume that “flights” in this case probably contains information about multiple flights, but is that returned in a table, an object, a data reference?

          Is that actually important? I mean it obviously is to the developer writing the code, but for the purpose of a code review or just generally understanding what the code does - why does it matter? I always found this argument confusing, to be honest.

          And inline declarations, like in your example, actually make it more clear how unnecessary HN is. We don't even need to care anymore what the type is - we're not even defining it explicitly. There is a danger element in this, of course, but it's not something that would be remedied by a prefix, anyway.

          Glad to hear you might consider letting go of HN. You'll love it. 🙂

  • The Hungarian Notation debate puts me in mind of global warming. You might be part of the minority who think man-made GW is a myth – but the majority of the world thinks otherwise – so you’re going to need really strong arguments if you disagree.

    Follow the money. If HN added stability and robustness to code, it would be used widely commercially. It isn’t. In my career, I’ve used a dozen or so programming languages. ABAP is the only one where I’ve used prefixes (until I thought – “what am I doing here, this is silly”). I didn’t even use them when I coded COBOL. (Or do you think that ABAP and HN is the betamax of computer science?)

    As far as I know, the only programming community in the world that uses HN is the ABAP community. Compared to other languages, ABAP isn’t a special snowflake. There’s no hot debate in academia about HN either – it just isn’t used. That demonstrates to me that all arguments in favour of it are feeble, at best. They don't stand the test of the real world.

    The arguments against HN are much stronger, validated and widely supported once you’re out of your ABAP bubble..

    I'm glad that SAP and DSAG both now recommend not to use HN. And as a result of that, I've got it written into one of my big client's coding standards.

    TL;DR Using HN, you’re not going to destroy the planet (deliberate use of hyperbole here, in case anyone is triggered). If you use HN in an otherwise perfect program, you’re settling for 99% perfection, instead of a 100%. You’re adding 0.1% to the Total Cost of Ownership. You’re making it very slightly less robust.



    • I think that the Hungarian Notation was widely used at Microsoft and has some older roots even in FORTRAN and BASIC.

      Anyway, the main reason that the HN has disappeared isn't because it is bad (it isn't), it's just because modern IDE allows you to get this info pretty quickly (although you still need some additional clicks).
      However, I still believe that the HN (or a similar notation) makes the code more readable.

      • Was widely used. In one company. But not much elsewhere. Is there any evidence that Microsoft's offerings were less buggy than otherwise... If their reputation is deserved, then probably not! ?

        As far as the IDE theory goes. Nice try, but also doesn't fit the facts. I've been programming commercially in non-abap languages (indeed some weakly typed ones!) since the late 1980s. We didn't use HN then, and we didn't have smart IDEs.

        You are of course entitled to your belief (and as I've said, HN/non HN doesn't make that much difference to readability), but the weight of the world's opinion (outside of the ABAP-o-sphere) is against you. And SAPs and DSAG's guidelines are against you. Do you know better than them? That's the question we should be all asking ourselves.

        To continue holding that belief you either need some strong evidence and arguments, or risk being labelled a "True Believer". 😮 😉 😀

        "no amount of evidence, no matter how good it is or how much there is of it, is ever going to convince the true believer to the contrary."

        - James Randi -

        In all seriousness though, I do wonder why people are so resistant to change. I know I was. But then I thought - let's give it a try, after all, I don't use HN in Java or other languages. So I tried it and found it led me to more readable code.

        In the same way, I tried declaring variables near to the point of use, instead of "at the top" in a COBOL-like declaration block. And again, the sky didn't fall in, and I found it again lead to cleaner code. In this case, it's because it forces you to think about what the name should be, and it discourages reuse. It also helps indicate where you can extract a method.

        • Well, to be certain in something you should either know everything about it or nothing at all.

          Regarding your questions, I’m not afraid of changes (and I even adopted some of the suggestions in ABAP clean code during the last year), but I don’t understand how omitting the HN would make your code more readable. May you please explain this part?

          Moreover, I saw now that even you are using some prefix notations for the scope. Why not to omit them also?

          (I already mentioned that I don’t see any problem with any customized/different version of the HN)

          • but I don’t understand how omitting the HN would make your code more readable.

            The question is, which is more readable?

            LOOP AT lt_material REFERENCE INTO DATA(lrs_material).


            LOOP AT materials REFERENCE INTO DATA(material).

            I contend the latter, you contend the formed. I’m utterly baffled why anyone would think the former is more readable. Sure, it contains more information,the benefit of that is outweighed by the hit on meaning. If you want to argue that the benefit/disadvantage goes the other way, I can understand that (even though it’s a minority opinion in the global programming community). But prefixes making the code actually more readable? I think not.

            Moreover, I saw now that even you are using some prefix notations for the scope. 

            This is true. But only for scope (global) and use (importing, exporting, changing, constant). I think the benefit calculation tips toward the additional information.

            I suggest that everyone be like Sam I Am. "Try them! Try them! And you may. Try them and you may, I say."

  • I must say I do sort of use the HN system.  I’ve never used it to name methods.   However, I have used it for local/global variables.  Really I only need the G or L.  The “personal” problem I have is that I want to use the same variable globally that I use locally.   So if I don’t have that G or L then I might not get a syntax error and yet, I’m doing something very wrong.   EX_ tends to remind me what needs to be exported, but really I can live without that one.

    I also tend to write my code for quick changes and easily readability.

    MMmmmm….  Now I have to try to write some code without using them and see how I do.  Great Debate, I’m sorry I missed it live.

    I tend to use field symbols.  Just for ease of use.  (I don't have to remember modify)  BUT I've never tried the last way.  So I might, but not on something that is used a lot.

    • Having just answered Shai Sinai with

      In all seriousness though, I do wonder why people are so resistant to change. I know I was. But then I thought – let’s give it a try, … So I tried it and found it led me to more readable code.

      I heartily applaud your decision to give it a go.

      Concerning references. I’ve started using them over field symbols. As noted in the article, there are some scenarios where you have to. My main reason is that typing the < and > signs causes a break in my typing rhythm. Also, they look a bit ugly.

      INSERT INITIAL LINE INTO TABLE a_bunch_of_records REFERENCE INTO DATA(a_single_record).
      a_single_record->field_1 = 'Some value'.
      LOOP AT a_bunch_of_records REFERENCE INTO DATA(a_single_record)
                                 WHERE ...
        a_single_record->its_one_of_those = abap_true.
      READ TABLE a_bunch_of_records INTO DATA(a_single_record) WITH TABLE KEY...
      CASE a_single_record->field_1.
        WHEN 'fish'.
          a_single_record->object = new fish( ).
        WHEN 'fowl'.
          a_single_record->object = new fowl( ).
        WHEN others.
          a_single_record->object = new abomination( ).
      do_something( CORRESPONDING #( a_single_record->* ).
  • I really don't (quite) get this distinct pro & con regarding HN. For me, it's a lot more important that whatever is used in a program is internally consistent. So, if the original developer used HN and did so properly e.g. following SAP's own guidelines from a couple of years ago with HN like "GV", "LT" and whatever, developers who later change the code should follow this lead and shouldn't introduce their own style for "their" pieces of the code. This IMO is what leaves readibility of code behind in the dust quickly.

    Code can be readible with or without HN but I admit that I'm a lot more used to code with HN as this is how I was introduced to ABAP code about 20 years ago both at SAP and at work.

    • That's why I like Eclipse for development. I can impose my style on legacy code as it's so easy to rename variables!

      The downside is that when you compare with previous versions, everything is changed.

      I'm pretty sure most people who use HN were introduced to it in their training. If you've never used any other language, I guess it would be a hard habit to break. I have programmed in many languages - and I found it hard enough!

      Maybe we could start HN users anonymous.

      Hi - my name is Matt, It has been five days since I last used Hungarian Notation... 

    • Yeah, that sounds like me about 5 years ago. 🙂 Then I thought "well, Matthew Billingham here said he does this, so I guess it doesn't hurt to try". Now I remove prefixes in the old programs (within the scope of the specific change, of course, I don't just go on some renaming bender out of the blue. 🙂 ).

  • Most annoying part of HN is, there is no universal rule followed across organizations about this. Every organization follows different rules.

    For example:

    Importing parameters: IV_, IM_, IT_, IS_

    Exporting parameters: EX_, EM_, EV_, ET_, ES_

    Object references: LO_, LR_, LREF_

    Weirdest I have seen is: K_ & LK_ for structures; I still don't know where they got the 'K' from to denote a structure.

    So, for me in the consulting world, every 6months to 1year, I have to learn a new set of rules. Few years ago, I said enough is enough, and created a simple program to rename all the variables in my program/class to match the rules set by the client organization. So, now a days, I write the code however I like and just before sending it for 'code-review' I run my tool to rename any variables where I haven't followed 'organization standard'.

    • Sadly, I've heard similar feedback from many consultants. Ouch! I had all this nonsense removed from the guidelines I worked on. I wish more customers listened to DSAG.

  • It’s funny how these discussions tend to go as if it’s all or nothing. Either you’re an alcoholic or never have a drop of alcohol. Either it’s HN or not a single prefix is allowed.

    Personally, I’m a casual drinker when it comes to prefixes. ? I’m with DSAG on using some of the prefixes (which define scope, as Matthew Billingham noted). C_ for constants is fine, it makes auto-complete useful as well. I’m neither for or against G_ for global (as we all know, global variables should be avoided in the first place). I like P_ and SO_ for parameters and select options in the reports but it’s more of a habit/tradition than anything else. (Aren’t they global variables? Why are they not G_ then? Think about it.) I’m fine with I_ / E_ for importing/exporting parameters and such.  Some of my colleagues insist on wasting 2 characters on this (e.g. IM_ / EX_ ). I honestly don’t see why but am willing to concede the point.

    Other than wasted space, my main beef with LS_, LT_, etc. is: (a) it can be misleading and (b) it’s redundant. (a) How many times did you see a structure called LV_something? Unless you implement some very zealous custom ATP check, it’s not enforced. And if I can’t trust the name 100% of the time then the point is moot. (b) We can only use an internal table with LOOP or READ, so what’s the point of adding LT_… to the name?

    All of this is just waste of time and energy. Then you just end up with useless debates at the code review. What for?

  • Most of the arguments about recognising variable types and code completion are only relevant in legacy code. The official ABAP guidelines have been clear on this since they were published over 10 years ago: Use HN in legacy code and/or keep it consistent with the rest of the code units you’re working in. Drop it for new stuff or code that follows modern guidelines.

    HN was useful 20 years ago and is still kinda handy in 200+ line lumps of code. But another thing I never saw mentioned anywhere in this discussion is that HN was easy and sensible when there were a handful of types and scopes. On R/3 2.1 we never had references and whatnot.

    But the complexity of ABAP keeps growing, new types are being added continuously, 7.52 gave us ENUM and now in 7.54 we got DEC32. HN simply doesn’t make sense anymore. Someone here argued that non-HN doesn’t show whether a variable is a reference or not. Well, the same applies to structure elements but there we don’t use prefixes. Why?

    How do we prefix a table of references? Or more complex things? Should we use LRTBRT_ for a local reference to a boxed table of table references? Personally I prefer naming variables simply and meaningful according to what they represent ?

  • And while we’re on the topic, three of my biggest pet peeves about prefix notation:

    There are a small number of sites with a class prefix convention that avoids ZCL_ but uses ZBLAH_CL_ or ZMMCLA_ or such nonsense.

    Using “g” for anything other than global variables. I’ve seen it used for class attributes. THEY ARE NOT GLOBAL! Personally I always associate “g” in code with “Gefahr”, the German word for danger.

    And on a couple of occasions I’ve seen “d” to mean elementary data types – as in ld_ instead of lv_.
    ​D = Data = the most generic data type at the top of the type tree that can be anything including a table or structure.