Skip to Content
User Experience Insights

Hungarian beginner’s course – a polemic scripture against Hungarian Notation

I love the atmosphere of constructive debating – lively and resolutely debated, but not becoming personal. In this mood, the following blog post became composed.

There is no other way around it by auditing, maintaining or understanding other’s coding: “lt_” stalks you! Everywhere! In SAP’s Coding. In customer’s ABAP code and in their official developers guidelines. In SAP-PRESS-Books of Rheinwerk Verlag, even though they also published the official developers guidelines of SAP (which tells us, that’s bad coding) – WTH their editorial office was hired for? I also think it’s a bad idea and I’m not alone with this opinion. I’m gonna tell you right now, why – in the following blog post.

Hungarian Notation, so it’s called in most cases, was invented by Mirosoft, which is a valid reason for being for most of the developers on the planet. That’s the tale.

The truth is: Founder of the Hungarian Notation was Charles Simonyi, an hungarian developer (that’s why it’s called “Hungarian Notation”) at Microsoft, who wrote an article, but it’s epidemical spreading misunderstanding by masses of developers around the planet was not his intention!

Following my main rule (“I don’t like metaphors, I prefer to speak in pictures”), I’ll illustrate the problems by showing it at an example:

Using three indicators to identify a data type

Let’s take a common data type’s name lt_ekko. What tells us it’s name? It tells us, that it’s a local table, which linetype equals the well known linetype EKKO. To make a long story short: It tells us masses of redundant information.

1. The local/global indicator

For an ambitious software developer, global data types don’t exist. We should not work with it, that’s what SAP told us for years, and they were right and they are still right – but why their own employees are permanently breaking this rule?

Developers, working with other programming languages, can not believe, that ABAPers work with methods of before OO was invented. In a well encapsulated environment, global data has no reason for being, because they are conflicting basically with object oriented software development paradigm.

And – this question may be allowed – what is the definition of global? All data types, defined in a program or class, are locally by definition, because outside this development object they do not exist. The only data types, which are existing globally, are defined in the Data Dictionary. Same as classes and interfaces (which are just data types with a higher grade of complexity): Global classes and interfaces are defined in SE24/SE80 and not inside an ABAP. A class, defined in an ABAP, is a local class by definition.

In conclusion to this statements, all so called global data types are also locally by definition (program wide locally, to be exact). This doesn’t touch the rule, that we should not use this, but in order to this blog post, it’s important, that an ABAP can not define global data types, so the prefix “g” won’t be used correctly. This results into the question: If everything is locally by definition, why the hell we do need a prefix for that?

And, pals: Don’t tell me, a static class attribute is the same like a so called global program variable, because it’s valid in the whole class and accessible system-wide! An attribute is called an attribute, because it has a context (the classes’ context!), this is way different from what a variable is! And the accessibility of such an attribute depends on it’s visibility configuration. A private attribute is not accessible system wide.

Updated 2016-12:
ABAP 7.50 brings the new feature of Global Temporary Tables, tonne defined in Data Dictionary. Because it’s accessible system-wide, it’s called “global”. There you can see, that a variable, defined in a program, is local byte definition.

2. The data type dimension indicator

The next question is, why I should use an indicator, describing the dimension of a data type. A table is just a data type, same as a structure or a field. In most cases, I simply don’t know, what dimension a data type has, I work with – i. e. while working with references and reference variables (what we should do, most of the times). And what is (from a developer’s view) the difference of a clear-command to a field in comparison of the same command to an internal table? It does simply the same: The clear command clears, what stands to the right of this command. It’s that simple. What kind of information will tell me the “t” in lt_ekko in this context???

What’s about nested tables? In


  begin of ls_main,

    materials type standard table of mara,


end of ls_main, 

lt_main type standard table of ls_main.

the table materials should be named lt_materials. No? Why not? Why a “such important” information, that this is a table, suddenly gets worthless, just because it’s a component? That this is a table, is only important in relation to the access context. Which means: For a statement like

ASSIGN COMPONENT ‘materials’ OF STRUCTURE ls_main ….

materials is a component, not more or less.

I’m not kidding: I really read some developers guidelines, which strictly orders, a field symbol has to have the prefix “fs_”, what is really dump, because a field symbol has it’s own syntax element definition “<…>“! Is this the way, a professional developer should work???

Next example is a guideline, which says, that I don’t have to use “lv_” for local variables, but “li_” for local integers, “ln_” for local numerics, “lc_” for local characters (which is in conflict to local constants) and so on. A developer needs to have a list of “magic prefixes” on his desk, to bear in mind this dozens of prefixes!

But this causes a problem: What, if you have to change the data type definition during development or maintenance process? You really have to rename it through the complete calling hierarchy through all of the the system, which means, you may have to touch development objects, only for the renaming process. You have to test all this objects after changing the code! What a mess! You need some Hobbies, if you need to fill your time, but not this kind of evil work.

It’s a well known rule: The more development objects you have to change, the more likely is, that you’ll get to objects, which are locked by other developers.

A public example: The change of data type definition from 32 to 64 Bit in Windows. All the developers, who have used Hungarian Notation, are now using a data type’s name, referring to a definition, which has nothing to do with it’s type!

What’s about casting? I could find more questions like this, but that’ll it for now, because it’s enough for you to get the key statement.

3. The structure’s description

This is another surplus information, because the structure’s or the basic data type definition is just a double click (in SAPGUI) or a mouse over (Eclipse) far from the developer’s cursor.

Now that we know, which redundant, surplus information we can get, let’s have a look, what kind of important information we won’t get from lt_ekko:

What kind of data we will find in lt_ekko? EKKO contents different kinds of documents: Purchase Order headers, contract headers, and so on. And by deep inspection, there are a few different kinds of Purchase Orders. Standard PO? Cross Company? What a cross company purchase order exactly is, depends on the individual definition of the customer’s business process, so it’s identification is not easy!

To get to know, what kind of documents are selected into table lt_ekko, we have to retrace the data selection and the post data selection processing, which is much more complex than a double click. For this reason, this is the most important information, we have to place in the table’s name!

If you select customers, what do you select in detail? Ship-to-partners? Payers? Or the companies, who will get the bill? Whatever you do, lt_kna1 won’t tell me that! ship_to_partners will do!Conclusion:

To get rid of all surplus information and replace them with relevants, we should not name his table lt_ekko, but cc_po_hdrs, to demonstrate: This are multiple (hdrs = plural = table, if you really want to do that) cross-company purchase order headers. A loop could look like this:

LOOP AT cc_po_hdrs     “<— plural = table

INTO DATA(cc_po_hdr).  “<— singular = record of



No surplus information, all relevant information included. Basta!

I am not alone

You may ask, why this nameless silly German developer is telling you me how you have to do your job? I am not alone, the following quotes proof:

“No I don’t recommend ‘Hungarian’. I regard ‘Hungarian’ (embedding an abbreviated version of a type in a variable name) a technique that can be useful in untyped languages, but is completely unsuitable for a language that supports generic programming and object-oriented programming”


  • Robert Martin, Founder of Agile Software Development, wrote in “Clean Code: A Handbook of Agile Software Craftsmanship”:

“…nowadays HN and other forms of type encoding are simply impediments. They make it harder to change the name or type of a variable, function, member or class. They make it harder to read the code. And they create the possibility that the encoding system will mislead the reader.”


“Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged—the compiler knows the types anyway and can check those, and it only confuses the programmer.”

Brain damaged“, to repeat it. Is this the way, we want to talk about our work, we should be proud of?


Of course, I know, that masses of developers will disagree, only because the always worked like this (because they learned it from others, years or decades ago) and they don’t want to change it. Hey, we’re Software Developers! We are the one, who permanently have to question the things we do. Yesterday, we did procedural software development, today our whole world is object oriented, tomorrow we’re gonna work with unbelievable masses of “Big Data”, resulting in completely new work paradigms, we don’t know, yet. And those guys are too lazy, to question their way of data type naming? Are you kidding?We are well payed IT professionals, permanently ahead in latest technologies, working on the best ERP system ever (sic!) and the SAP themselves shows all of us, that they can throw away the paradigms of 20 years to define new ones (to highlight the changes to S/4HANA, I never would have estimated as possible).Let’s learn from our colleagues, who also develop applications with a high grade of complexity. Let’s learn from the guys, who invented the paradigms we work with. Let’s forget the rules of yesterday….


I’ve been asked, lately, if I don’t like prefixes at all. The answer is: No. Indeed, there are prefixes, indeed, making sense:

  • importing parameters are readonly, so they may have the prefix “i_”.
  • exporting parameters have to be initialized, because their value is undefined, ifthey are not filled with a valid value. So we should give them a prefix “e_”.
  • changing parameters transport their value bidirectional, so they should marked with a “c_” and
  • returning parameters will be returned by value, so we should mark them with prefix “r_”.

This is a naming rule, I’d follow and support, if requested. Because this prefixes transports relevant, non-redundant information (in terms of the things, which are not obvious), influencing the way we handle this data types.

 Request for comments

 Your opinion differs? Am I wrong, completely or in some details? You’d like to back up me? Feel free to leave a comment….                                                                                                                                                                                 

Disclaimer: English ain’t my mother tongue – Although I do my very best, some things maybe unclear, mistakable or ambiguous by accident. In this case, I am open to improve my English by getting suggestions 😉

You must be Logged on to comment or reply to a post.
  • Hi Ralf,

    I can see all your points and you're so right. ➕ But I can't change my company's ABAP coding rules, which differ on several systems, but all take use of HN in different ways.

    So I can agree with your opinion, but not follow your ideas. HN will survive in ABAP still for a long time.

    Thank you for this ℹ document. Great job. I've really enjoyed reading it. 😀

    Best regards,


    • What the world would look like, when Martin Luther would have been said: "But I can't change the church") Or if the people in GRD would have been said: "I can't change the country and it's government"?

      It might be a long way, but it's worth it. Each revolution begins with one or a just a few people, beginning to speak.

      • Hi Ralf,

        in a global company with 100.000's of employees you have several hierarchical levels. Coding guidelines for our SAP system line groups come from some levels higher than mine.

        I've to follow them and fill out a coding checklist, where I have to check and confirm all checkpoints. One of them is to confirm, that I followed all given naming conventions for program names, DDIC objects, variables, constants, internal tables, and so on.

        The naming conventions are different for several groups of system lines, because there are other company IT's responsible for that. But all of them are using HN.

        Also some of our system lines were introducing SAP HANA, nothing changed concerning the naming conventions.

        Another point is, that some of our SAP systems where created in the 1990's. So a new notation may not be welcome, because if you copy an existing program for a new one, you'll have to change too much code.

        Anyway I like your suggestions, but I'll not be able to follow them. Nowadays a Lex Luthor will have more success than a Martin Luther: Buy a company and dictate the rules. Until this happens, HN will last in my company.

        • Klaus Babl wrote:

          Another point is, that some of our SAP systems where created in the 1990's. So a new notation may not be welcome, because if you copy an existing program for a new one, you'll have to change too much code.

          You really copy programs 25 years old and expect them still to do the right thing? Why are they copied? Shouldn't they refactored when they need new functionality? Or being completely rewritten following the oops paradigma?

          • Hi Rainer,

            yes, programs may be 25 years old, but these, who are in use today, will have been changed several times. So the last version may be some months old.

            If a part of the company is sold or gets another legal status, new data migration reports must be written. Because this may happen several times a year, the reports of the last migration may be used as a template. Also users will be switched to other SAP systems and switched back, if the processes can't fit all requirements.

            In big companies there is a permanent restructuring, and it's never completed. So you may need several versions of the same program parallel in the system.  But for thes versions are living, you can't handle that with IF's and CASE. Sometimes completely different role and authorization models are behind these program versions (Z-authorities vs. SAP authorities, ...) print programs will be different, ... .   

            Looks like most people here in SCN are working in small and medium companies ... 😉



          • For migrations we are always generating new programs. Yes, generating, not coding. I've enhanced the abap patterns so via a dialog a just make some clicks zo get reorts covering 75 to 80% of all our migrations in the passed. No copying needed, less programmer resources needed.

            Hey, you are a programmer! Let the machine do dumb work 😆

          • I was advised to copy a single run program to do a material data migration. It was a mess and I wrote a program, working with OO and reusable for each material data migration in the future.

            I'll post an article about that next week....

            Means: There are other ways than copying old programs to make "new" ones.

          • If I would do so, next programmer will copy an old non OO version for next data migration. And he may be from Czech Republic, India, Hungary; Poland or somewhere else over the world and never have heard my name. Because he'll get his functional specifications document from demand or application management without comments or hints from any other programmer.

            Maybe he'll be an employee from a service provider or a freelancer. The only thing he will get beside the func. specs. are our programming guidelines and naming conventions (containing HN).

            But also if I create a completely new one I will copy some sample includes of mine and don't start with an empty editor.

            Nevertheless your blog is great, but introducing it into my company is like tilting at windmills. Only persons in the Corporate ITs may start such suggestions. But we have tons of country specific Corporate ITs, while some of the SAP systems are transnational systems. So the locale ITs who have the maintenance for the SAP system create their own programming guidelines and naming rules for their maintained SAP systems.

            I'm not a member in such a maintenance IT, but in a Global Service IT like an inner company service provider. So I'm not allowed to be creative, if I get fixed instructions.   


      But you can start a discussion. Curiously enough, the person responsible for the development guidelines will also not survive for long if this person makes very unpopular decisions...

  • See here: ABAP Modern Code Conventions and you'll know you're not alone at all. I use x_ for changing parameters and c_ for constants.

    I had the opportunity to update the coding standards of a multinational company a few years ago, and I removed all the stupid prefixes they had.  Dumb sheeplike programmers 😉 there still continue to use HN, but the standards don't say anything about it - just that they should use meaningful names.

        • *rolling out the red carpet* Moin Horst 😉

          These standards as well as one of the books, you wrote (in English, it has the name "Official ABAP Programming Guidelines", I think)

          • Yes,  "these standards" and the book are the same. Alas, there are also other standards around at SAP. "These standards and the book" represent the ABAP language group's point of view. Many other groups are great fans of prefix naming conventions.

            B.t.w., my favorite proof of senselessnes of prefix naming conventions: I don't know any of those that prescribes the names of components of structures.  Put all your data objects into one structure and you are free 😈 .

            In fact, I once tried to create a prefix naming convention that is free of such contradictions. I think I succeeded, but the result is even more unreadable ...

  • Totally agree. i'm in the happy position to be responsible for our guidelines. And guidelines should be as small as possible, if not,they are not followed. How long do you wanna treat a new programmer until he is following all the rules?

    Even the e/i/c/r prefix is not mandantory here. If someone wants to do that, he can, but then he has to use those mentioned. Our guidelines are less then 50 pages and i think they are still too big. Naming conventions is one page ( i have some for methods saying that some of them must start with a verb like set_ get_ is_ and so).

    Naming conventions are only for maintainability and even for that of low value. They do not add something on robustness, security, performance, compliance or data loss prevention.

    Its more important to force the evaluation of the return code. How often do I see that the returncode/exception is picked up, but there is no action when it fails. All the if sy-subrc <> statements are commented out

  • Someone just made my day!

    This conversation actually happened between me & a developer who recently joined the project.

    Developer: "Where's the naming convention sheet?" 😐

    Me: "There's one, but it's old & outdated and nobody follows it! " 😎

    Developer: "Ahh, therefore all your variables are named wierdly - customers, customer_open_items etc. "

    Me: "How would you do it rather?" 😕

    Developer: "lt_kna1, lt_bsid ... Everyone knows which table data is being processed!"

    Me: "Well, in that case, you can find the naming convention sheet in the .... "

  • Excellent stuff Ralf.

    I suggested something similar to my team just last week. Not much support unfortunately 🙁

    I was going to give you 5stars, until the end. But cc_po_hdrs doesn't tell me much more than lt_ekko (po could mean process order, for example).

    You could also make a case that shared memory objects are in fact global data, but let's ignore that for now 😉



    • I have a craving to use CamelCase for variable names e.g., CustomerOpenItems. IMHO they look better than customer_open_items, makes me feel more nerdy 😉

      But the pretty printer doesn't quite agree with me on this one 😛

    • PO is the abbreviation for purchase order, system-widely. The header of ME23N is "Standard PO..... created by.....".

      In fact, you can choose "cc_purch_ord_hdr" if you want to be more exact. "cc_po_hdr" is just a suggestion, not more or less. The key is, that you can see: this table contents purchase order, cross-company, that's massively more than "lt_ekko", which does not say, that this are purchase orders nor that cross-company detail. because "cc_po_hdr" maybe not exact, but it's more speakable than "lt_ekko".

      • I know cc_po is a suggestion, but IMO a bad one. CC says nothing, and PO says little (as I said, we use PO for process orders here) and if your point is to have meaningful names, it doesn't help much. I tend not to abbreviate unless it's really necessary (ie DDIC limitations etc).

        Still, congrats and thanks again, very nice blog post.



  • Great blog, Ralf!

    My company is quite small and we don't have naming conventions... just because nobody cares 😉 I mean that few developers feel pretty comfortable discussing such ideas having coffee. And as soon as we turned our attention to OO style we followed the same steps: removing local/global description, making variable names more meaningful. It seems that such process can be quite evolutional. If someone feels uncomfortable quitting using HN, after the "magic OO enlightenment" he can try his own easy way to stop smoking using HN 🙂

    So, I'm on your side.

  • Nice read, well done!

    Over the years I'm using less and less HN in my coding. At the moment I only use I and E for importing and exporting and v, t, s for single value table and structure.

    The rest just faded away through the years, especially fs_ for field symbols that's clearly bordering on insane and whenever I see it in coding guidelines I question the sanity of its author.

    I also found out that over the years I use longer unabbreviated data statements e.g. lv_discount_percentage, instead of lv_discper or similar.

    Cheers, Rob Dielemans

  • Good post. I've been following more or less the same lately plus getting rid of arbitrary abbreviations like hdr unless dictated by the data dictionary. No need for that IMO.

  • Prefixing the scope and the "kind" of data within the data and procedure interface declarations means... routinizing these activities and categorizing the result.

    Routinization and discipline are good... and only prefixing IMO enables the most effective use of code completion features (applies to class, interface and especially the method names as well). Code completion is the next best thing after *ahem* ... where-used-list.

    Splitting hair over the meaning of "global" is purposeless and unhelpful; routinizing and categorizing class member declarations - isn't... 🙂

    I have to deal on a daily basis with two important ABAP programming disciplines, where the use of global data declarations is literally unavoidable:

    - dynpro programming, including selection screens (telling not to use dynpro in a system built on it is... purposeless and unhelpful)

    - Print Workbench Application Forms: Transferring Own Data to a Smart Form or PDF-Based Form

    As their use grows, the naming of field-symbols should IMO follow the scope and kind of the data or parameter they are used to refer to...

    LT/LS_EKKO is lazy, but I'd still take it over CC_PO_HDRS/CC_PO_HDR - any time 🙂



    • Print Workbench Application Forms

      How can one not hate those? Those T*, WA* global variables are a nightmare 😈

      Tbh, i like the idea of PWB Forms; separation of (reusable) business-application logic from the form.

      But the implementaion of PWB is a total mess.

      • So long as the only acceptable use of "user-exit" is to call procedure(s) (formroutines or methods) in order to pass the global data - problem largely aleviated. It's basically reduced to "mapping" (and initializing my own global data) - nobody is forcing me to work with global data beyond that.

    • II'll give you three suggestion:

      Of course, screen fields are globally, but you do not have to work with it. A screen calls modules, and each module only has a method call. Within the method, you can work with the local variables by ignoring the Globals. Look at SAP transactions, i. e. VA03: The screen field has the same name like a DDIC field, means: VBAK-VBELN, without any g_ or any other prefix, and this makes sense, because it's the easies way to inherit all attributes (translations, etc.). So you do not use any prefixes for this.

      When I design a report, it has a selection screen. Each global variable is only used in the method calls, the operative coding is encapsulated in classes.

      I'm not very deep into the form building process, but as far as I remember, the difference between SAPscript and Adobe PDF is, that an Adobe form has a well defined interface, which a SAPscript does not have.

      Field Symbols:

      DATA: material type mar.

      FIELD-SYMBOLS: <marafield> type any


      ASSIGN COMPONENT sy-index of STRUCTURE material to <marafield>.



      Which prefix this FS should have? Of course, it is local, because global field symbols are very bad, but it does not have a specified type.  I very often use references and field symbols....

      • So long as "global" data is in use, it makes sense to restrict and to minimise access to it - via proper modularisation, and passing this data via parameters (interfaces of the modularisation units). So the only acceptable use of globals in "global context" is - to pass it to local context... Local contexts (procedures) should not work directly with global stuff. I agree. True for OO or for procedural programming but that is another topic entirely...

        So long as global data is in use, it also makes sense to designate it so in naming... gs_vbak or even public go_sales_document_ui->ms_header, defined with a reference to proper DDIC type, inherits within the dynpro context much if not all of the good DDIC stuff as well.

        Right, I too don't see the need for using "globaly" defined field-symbols. Within procedure context, hoverer, field-symbol referring to an  input table line I'd name <is_....>, changeable table line <cs_....> and so forth 🙂 . This is my preference, field-symbols are not part of our guideline.

        Don't get me wrong: naming conventions so elaborate that they need to be referred to just to get your work done are counterproductive. I just checked - we use 11 rules for the first symbol and 9 rules for the second prefix symbol... I have never encountered confusion or been slowed down due to the fact that s is used as first prefix symbol for both the select-options and static member variables, and c is used as first symbol both for changing parameters and the constant definitions in a global OO interface... The contexts in which the definitions are made and used are distant and clear enough. The apparent "inconsistencies" of the notations and conventions are for the most part blown out of proportion, IMO.

        • Giving dynpro fields the same name as the corresponding DDIC fields makes sense, since the data transporting is done automatically and the dynpro fields inherits all attributes.

          Using prefixes generates dump work for the developer. You did not answer my question, what prefix <marafield> should have.... Particularly if "material" is a deep table....

          • "Same" principle for field-symbols as for declarations. If it's local data I'd define ls_material and <l_material_comp[onent]> and would only protest if someone tells me it's absolutely verboten, because ...

            The differentation IMO makes sense both from readability and code completion perspective just as soon as the modularisation unit has is_material on input and I need <i_material_comp[onent]>... Add returning rs_material and <r_material_comp[onent]> to the mix and I hope it's clearer what i'm trying to say.

            I'd not protest if someone omits prefixing for local stuff. If, however, that someone then starts writing <marafield1> <marafield2> ... I would 🙂

            Edit in: I don't think I have ever dealt with something like that, but if the structure component is a table... the field-symbol would have to be... <.t_materials> ...

          • A field symbol is always locally, so you don't need the "l". You never worked with deep structures? R U kidding? But, if you are right and you never worked with it, you need rules for that, because you are not the center of the universe. I often work with that.

            You do have the same problem by defining a deep structure or table, so this problem is not field symbol specific.

            And there is still the question: Which advantages do the prefixes provide?

          • The definition of field-symbol is local, the data that can be assigned to it is either local or that from the input, changing, exporting or returning parameters - within the context of a method.

            A complex, deeply nested structure is "at the heart" of Print Workbench - table components are prefixed using t_, structures using wa_ (I'd have preferred s_). I don't think I have ever encountered the need to process/traverse it using genericaly typed or untyped field-symbol(s). There may be some uses for them - I just haven't seen them yet.

            If there is a good reason to deviate from naming convention in some scenario (or any convention, for that matter!), then it just needs to be done. If the naming convention does not apply to, say, 5% of the code, it might need a revision. I'd still argue that it does not justify discarding convention entirely.

            The prefixing (categorising stuff) IMO makes code easier to understand and, I believe, saves time - by enabling more efficient use of code completion feature... I don't have anything that can be described as "evidence" in this regard.

            Peace 🙂

          • OK, you may code against the recommendation of all the people, I quoted in my blog post (and against the recommendation of SAP and lots of comment-writers here)...

            Let's hope, that you never write coding rules, other developers have to follow....

          • The prefixing (categorising stuff) IMO makes code easier to understand

            If this were true then it would be common practice in other commercially used languages. It isn't common practice in other languages, therefore it isn't true.

            In practice it doesn't make code easier to understand, therefore it is just noise, and therefore shouldn't be used.

            Seems like simple logic to me. 🙂

          • I don't have enough experience or view broad enough to argue this one way or the other, but prefixing has played and still plays a role in naming conventions in other languages (what I remember off the top of the head: g_* for globals, m_* for members, s_* for statics, has, is, can for booleans, I -- or was it i..? -- for interfaces, and "something" for constants).

            I don't think it should be controversial to state that 1) the naming should reveal the intended use as much as possible or that 2) routinizing and standardizing (striving for consistency in) naming are good. That naming conventions do have utility beyond avoiding collisions and ambiguity in other words. And that "readability" or "understandability" also play huge role, but these are necessarily subjective criteria - one would need to poll the intended target audience to say something one or the other way, and familiarity with conventions under consideration, or lack thereof, would skew the results.

            Prefixing, when not taken to extreme, IMO helps to accomplish 1) at the first glance (without having to "hover mouse cursor over this or that in IDE" 🙂 ), works towards 2) and helps to define simple enough, easily grasped and followed rules. You too do not reject all of the prefixing, so what is argued about is how much, where.

            I hope I could live with the "casing" conventions as well (since many programmers do); not having to have to adhere to one until now, intuitively prefixing feels simpler to follow (in addition to revealing more about the intended use).

            It's good to be for once put in the role of a naming "oppressor" 🙂

            @Ralphf I don't believe conventions should be imposed without sufficient discussion in the team. I can sympathize with those having to adhere to several conventions (moving from assignment to assignment) or clearly excessive conventions.

          • Well, what do I "speak"?

            Fortran, Cobol, Pascal, C, Rexx, CList, Java, Abap, Python, PHP,

            In each company I saw naming conventions, but never using prefixes like G_ L_ or whatever.

            Except for ABAP.

          • Technical University, tiny bit of IBM can't remember what Assembler and REXX, tiny bit of BS 2000 macro Assembler, little bit of Adabas/Natural (with truly "oppressive" conventions), ABAP, ABAP, ABAP, ABAP, ABAP.

            85 visible lines in GUI editor, 83 in Eclipse. 🙂

  • I program in many languages and can tell you quite categorically that HN in a reasonably strongly typed language (such as ABAP) is a waste of time.

    Logically, since typing prefixes (as opposed to usage prefixes) add no value and reduce readability, they shouldn't be used.

  • Good blog! (Well, it's good to see anything intelligently written on SCN these days. 🙂 )

    To start with - I'm not disagreeing with you at all. But upon reading the blog I'm not very clear what specific actions are you suggesting to the readers. Actually I had the same question as Custodio de Oliveira above - cc_po_headers is not much of an improvement. Following the same logic (what if something changes?) - what if we decide to also select other document types, no just POs?

    There have been a blog on SCN few years ago on naming conventions, it went along the same lines. And I want to improve my skills, so I try abandoning old conventions and to use simply descriptive names in new programs (the old ones are a different story). But then I end up spending too much time just thinking what the more appropriate name would be. Ship_to_partners is a good but just one very specific example. Most of the time we select data from 5-6 different DB tables into one and it could be, say, sales order + delivery + invoice data. What should this be called? itab_data? Oh wait, no... Simply mega_report_data? By the time I make a decision a cheaper developer would've already typed itab_vbak and moved on. And then management somehow does not appreciate my effort but prefers to have s*t done ASAP.

    Also I am a lucky "owner" of our guidelines (3 pages), but, to be honest, naming conventions in my daily life are problem # 99 or so. I have to deal with consultants who can't write a JOIN, so in fact I'm absolutely thrilled when we get at least lt_ekko instead of itab1. The problem is - I can write the guidelines but I can't chose people who will be using them. So, to be honest, I'm just not picking this battle.

    Thank you!

    • I do have this difficulty sometimes, but then I get a grip and realise I'm probably over-thinking the issue. In the context of the development what am I actually doing. For example, if you have to write a report which selects from five different tables: vbap, vbak and a few others, you could use for example

      • If the driver is sales orders from VBAK than SALES_ORDERS and SALES_ORDER.
      • If the driver is all kinds of orders, then ORDERS and ORDER.

      I've written programs where the main internal table has simply been named "the_data". In some contexts, that's absolutely fine. In BW, we refer to the data we're processing as the package. So that internal table is (since it's changing) c_package. Loop at c_package assigning <package_line>.

      Choosing names for variables is a tiny fraction of overall development time. Since you're a decent programmer, probably while part of your consciousness is puzzling over a variable name, the other part is probably designing the program structure. The lady doth protest too much, methinks.

      Bad code with variables with not very good names written by a cheaper developer is considerably more expensive than good code written by an expensive developer. Research in the 70s by IBM suggest that code written by bad developer is 20 to 50 times more expensive, over its lifetime, then code written by a good developer. I assume you're not 20 times more expensive than the so-called mis-named "cheaper" developer.

      • Matthew, it was not a protest (as stated at the very beginning), merely an explanation of  why exactly nothing will change after this article in the real world. (Now if this was called 'Russian notation' I might have had an axe to grind here. 🙂 )

        By the way, found the old blog (by Chris Paine, unsurprisingly 🙂 ):

        As we see, not the whole lot of progress since 2013.

        • It was an article like this that changed my way of ABAP programming in the real world! I suddenly thought "I don't program like this in Java, so why the zarking fardwarks am I doing so in ABAP".

          • I guess that explains it - most ABAPers "don't get out much" (to other languages). 🙂

            Out of interest dug out the 2004 book 'Enhancing the Quality of ABAP Development'. It proposed to use th_ for hashed tables vs. ts_ and tp 'for most variables', e.g. tp_matnr (the authors lost me here). But it does also suggest to use meaningful names, such as ta_orders instead of ta_itab. Personally though I wouldn't mind ta_vbak either. My expectations are quite low. 🙂

          • Yes, and it is outdated in some ways. The rule "do declarations at the beginning of the procedure" (rule 4.13) does not fit to inline declarations. But the main direction was right and (as I wrote) it is still right.

          • This is exactly the way I use it. Single use variables, field symbols which are used once in a loop and nowhere other, etc. But for this cases, it's great, because it lightens the declarations block.

            For all other declarations, I do have the strict rule, to follow ABAP Doc conventions and I highly recommend that to my customer's developers, although they do not work with Eclipse, yet. But after changing the IDE, they will get all the advantages.

  • Long long ago, when I started as an ABAPer, one of my jobs, was to review other's code for these naming conventions and report them in the review sheet. That gave me a chance to see

    1. how developers who are more experienced than me - wrote their code

    2. thought process/ logic applied

    3. how they arrived at the solution

    4. etc

    So one day, I got a report to review. The variables/ internal tables were all "incorrectly" named. So, I noted in the review sheet:

    1. Internal tables not declared correctly. Currently declared as ITAB_*, recommended usage LT_*.

    2. Variables not declared correctly. Currently declared as WA_*, recommended usage LS_* or LV*

    I send back the code along with the review sheet to the developer. 2 hours later, I got the same code for re-review. Now, the internal tables where declared as LT_ITAB_* and variables were declared as LS_WA_*.

    The developer just prefixed whatever prefix was required by the "naming convention document", into the original variable name.




    • Juwin Pallipat Thomas wrote:

      The developer just prefixed whatever prefix was required by the "naming convention document", into the original variable name.




      I would laugh if it wasn't so tragic.

      Ah, whatever, I'll laugh anyway 😀 😀 😀

      • If you liked my earlier one, I got one more....

        During the same time period as earlier...

        One of the "coding standard" was, all the subroutine definitions should be written alphabetically in the program source. Meaning, if the subroutines used in the program were with names:








        The "coding standard" required that the developer write these routines in alphabetical order.








        Needless to say, one day I had to send back one of the programs, for this reason. After the "fixes", the code was written alphabetically now, but the subroutine names were changed to:









        The developer didn't really alphabetize the code. But, instead he changed the subroutine names to match with the order written in the program.



  • I've been asked, lately, if I don't like prefixes at all. The answer is: No. Indeed, there are prefixes, indeed, making sense:

    I don't like prefixes at all. Prefixes are unnecessary if you can see the complete source code of a method on the screen without scrolling (in the mode where the signature part and the class tree being expanded).

    BUT in reality - as long as the average methods produced by ABAP developers are way longer than that, some prefixes are useful.

  • Great topic.

    I must confess, I have been using some form of the HN for most of my ABAP career.  Mostly because, that was how it was done by predecessors and peers.  I have read through, although it has been a while, Horst's book Programming Guidelines... and adopted some of it's conventions, input, export, etc. parameters.

    However, there is plenty of food for thought here, in Ralf's original post, as well as the myriad of posts.  I tend to agree, that the prefixes are unnecessary.  Just don't look at what I have already done.  I will have to re-evaluate with the next project.  I am fortunate that I am not concretely bound to corporate naming conventions.

  • Just one question which I had doing some abap stuff. Nowadays dealing with internal tables is quite simple having field-symbols. But now and then a structure is required to work on tables. How do you name the internal table and the working area? Using  prefixes? Or plural.S like "customers" for the table and "customer" for the structure?

    • A table of entries are more, an entry is one - so I use plural S for tables and singular for work areas. But I don't know how long I did not use workareas. I always use field-symbols, because the syntax element is very unique compared with a table and an access to an unassigned field symbol dumps, so I can see, that there something is going very wrong.

      A workarea is just empty.....

      • It might be a matter of preference, but I find that just adding 's' does not provide a sufficient visual "clue". To me personally '_line' looks more clear, although it can make some names very long. A single letter at the end is just difficult to see when quickly 'scanning' the code, so either field symbol or something more descriptive would be preferable to me personally.

      • I had to collect data from various resources into a table. Later on, I need to take the decision depending on these collected values to store the data or not. Either I'm collecting the data in a workarea not storing the values later on or I use APPEND INITIAL LINE ...ASSIGNING and need to get rid of the obsolete row later on. This was the point where I decided to use a workarea and from my point of view there should be a relationship by name between structure and table. In former times I used IT_ and WA_ but i'm always looking to improve and see how others are working.

      • Workarea vs. Field-Symbol - reminds me of the age old discussion of using Parameters by value or by reference.

        And of course, the advantages, as well as the riscs are similar.

        WA is:

        • slower (in comparison),
        • produces redundant data (for the time beeing)
        • needs an explicit command in order to make any alterations manifest.


        • it's safe against unintended alteration of tabledata
        • except for really huge tables, the difference in speed does not matter

        Both have their benefits and their respective usecase.

        But seeing (here on scn too), how poorly understood field-symbols often are, i'd think twice before advising anyone to use them merely as a substitute for WA.

        But as for your main campaign, i mostly agree - unless of course, you have to maintain ancient code. - in my opinion it makes things worse to start mixing HN with "proper naming".

        Either rebuild from scratch or stick to the naming conventions already beeing introduced in the code.

        Best regards - Jörg

        • Du you really think, that the performance feature is up to date? AFAIK, ABAP internally works with references, even when working with work areas (lazy update).

          I don't believe, that working with work areas is slower, even for huge tables. And the redundant data is only shown for the user, because internally this are references, as well.

          As I said: As far as I know.....

          • Have fun: =)

            TYPES: BEGIN OF huge_tab_line_type,
                      tab TYPE re_st_tabix,
                    END OF huge_tab_line_type,

                    huge_tab_type TYPE STANDARD TABLE OF huge_tab_line_type.

            CONSTANTS big_number TYPE int4 VALUE '1000000'.

            DATA huge_tab      TYPE huge_tab_type.
            DATA huge_tab_line TYPE huge_tab_line_type.
            DATA tmp_tab       TYPE huge_tab_line_type-tab.
            DATA t1            TYPE int4.
            DATA t2            TYPE int4.
            DATA t3            TYPE int4.

            DO big_number TIMES.
               INSERT sy-index INTO TABLE huge_tab_line-tab.

            DO big_number TIMES.
               APPEND huge_tab_line TO huge_tab.

            CLEAR huge_tab_line.

            GET RUN TIME FIELD t1.

            LOOP AT huge_tab ASSIGNING FIELD-SYMBOL(<huge_tab_line>).
               tmp_tab = <huge_tab_line>-tab.

            GET RUN TIME FIELD t2.

            LOOP AT huge_tab INTO huge_tab_line.
               tmp_tab = huge_tab_line-tab.

            GET RUN TIME FIELD t3.

            WRITE: / 'FS: ', |{ ( t2 - t1 ) }|, 'microsecs'.
            WRITE: / 'WA: ', |{ ( t3 - t2 ) }|, 'microsecs'.

            My system says, it takes about twice more time when I use work areas. But the difference can be seen only on _really_ huge data objects.

          • Hello Nikolay,

            the assignment has also a performance cost. There is a work-area width/size limit, what you need to reach using field-symbols. Below that size, the field-symbol assignment is less efective, but above that size it becomes more and more faster. It is written nowhere, it was told to me years ago, on an internal training session in my SAP employee days. Ask me not what that size is 🙂 , I forgot, but trainer talked about bigger work-area width, with lot of fields. That was the 100% sure part so far, now here comes my theory 🙂 :
            Your work-area is not that wide, but rather deep, because consists only of one component, which is a reference to your large internal table only. Such way using field-symbol, just to iterate over an internal table, where each line consists of a reference only is much slower of course. Overhead is the assignment costs. Power of field-symbol is for example more obvious, when you need to change field values during iteration over an internal table with flat structure, because this is motre efficient than move.

            Best regards


          • Hi Attila,

            That's why I posted a sample code for people's researches - everyone can check it out on his/her system. Changing of field values wasn't taken into consideration intentionally - I wanted to check the difference only in "read" access thus making field-symbol's life harder.

            Being buzy at the current project I hope that someone finds enough time for a thorough investigation of the "field-symbol mystery" =)

          • Ralf, you're right there.

            Even more reason, not to glorify field-symbols as the all-time-best way, to process tabledata.

            Don't get me worng - i love field-symbols and wouldn't get half my Job done without them.

            But still, there's a wide spread ignorance of what they are and how they work.

            Just do a search for field-symbols here on scn and you'll have a hard time to get your breathing even again,

            It's just that my spider-senses jump to attention, whenever use of field-symbols is advertised indifferently.

            I have even known developers beeing reprimanded for using FS without need.

            Curiously, it's something not well regarded, especially in companies, where HN is held in high esteem.

            BR - Jörg

          • I suspect that until we can have the exact definition of how much is "narrow" vs. "wide" the best understanding we will see is: "for read-only use work area, for modification - field symbol".

            Although even this is not bad because many developers still seem to be blissfully unaware of FS as such unless they need to do some "dirty ASSIGN".

    • I always use something meaningful and readable, without having to memorise a list of arbitrary conventions. Pluralise (customer, customers) if that makes sense, otherwise using words like line or record.

  • I'd originally missed this post, been reading up now. Excellent post and comment thread, I had a few good laughs. Thanks everyone!

    To add my own most recent experience: at my current client HN is also used, but just to make sure everyone understands we're doing custom development all variable names have to start with zlv_ instead of lv_, zlt_ instead of lt_ etc. 🙂 .

    • zlv_ is awesome! 🙂

      And what about modifications of standard code? Do you still need to use zlv?

      We can go further and add some more meaningful information like this:

      fred_20151008_zlv_total_sum = REDUCE #( INIT fred_20151008_zlv_sum = 0 FOR wa IN alex_20151006_tab NEXT fred_20151008_zlv_sum = fred_20151008_zlv_sum + wa-betrg ).

    • Fred Verheul wrote:

      Excellent post and comment thread, I had a few good laughs. Thanks everyone!

      You are so right. I am SO thankful for all the great comments in this thread and so much likes and ratings, which made me Bronze 😉

      This seems to be a great community, which I had ignored for a long time (mostly because it's all English, here - but my English is going better and better every day). I never expected so much feedback with my first blog post.

      So, thank you very much to all the readers, raters, likers, commentators for giving me so much feedback - and I include here the ones, who made me learn (i. e. due to abbreviations) and widen my scope/focus.

  • It was a standard notation to follow the naming conventions which are not required, Compiler is clever enough to identify based on the types.Good article.

  • I am horrified, but not in the least surprised, at the horror stories of developers working for really big companies who are instructed that thinking for themselves is verboten, and have to follow silly pointless rules that actually hurt the company on the grounds that these are the rules and we have always done things like that.

    I used to work in such an environment. Once I was told that it was compulsory for me (and a few of my colleagues) to fly from Germany to the UK for work on a certain week. Fine I thought. Ten minutes later the same manager - the one who had sent the instruction in the first place - sent another email to us all saying could we now all please fill in a form and then email it to him asking for permission to fly to the UK.

    There have been similar blogs on this subject in the past, and I am just like Matthew in that I started off naming everything LT_ and GD_ and so forth - mainly because I dealt primarily with monstrous procedural really old programs and I was trying to get my head round what was local, what was global (far too much) and what was a parameter, as the naming was all over the place and often L_THING was a global variable, and there were several OK_CODES, some global from the DYNPRO screen, some parameters, some declared locally inside a routine, often all three at once and you had to work out which one was getting changed.

    However once I get to a stage where I know what is going on, then is the time to start using methods and what have you, this enables unit testing, but what I most like about OO is it lets you write code like English sentences, and then you don't need comments.

    When I write something like this:-

    r_value_is_valid_if = there_is_a( characteristic_value = entered_by_the_user

                                                         in_the_patterset       = specified_in_the_rule ).

    I jump for joy, because when I come back to it six weeks later I know what it was I was trying to do. This is the so called "literate programming" espoused by Donald Knuth creator of the famous "Spiderman" programming language.

    Real English sentences don't have words like LD_ENTERED.

    As an aside, by understanding is that the Hungarian gentleman in question worked for Microsoft and wrote a big article about what later on came to be known as "Hungarian Notation". The introduction explained about using prefixes for variables names and why people might desire to do such a thing, and the remaining 95% of the article was a series of arguments designed to demolish the whole concept, saying why it was a Bad Thing and for God's sake never do this ever.

    But nobody - including the management at Microsoft - every bothered reading past the introduction and so concluded he was in support of such a concept, and before you knew it, Hungarian Notification was official Microsoft policy,

    That must have hurt - it is like writing a book on why it is good to be a vegetarian and then going down in history as King of the Meat Eaters for time immemorial.

    So it is not only authors like Robert Martin who rail against the use of Hungarian Notation, but also the inventor himself!

    Cheersy Cheers


  • I don't agree with article. Only with one moment - may by "l" and "g" are superfluous in prefix.

    But using "t_"(internal table), "s_"(structure), "v_"(plain varible), "r_"(reference), "o_"(instance of a class) and the same in field-symbols ("<t_...>", "<s_...>" and so on) makes code more readable and I have no need every time when I see new variable to find its defenition. Especialy it make sense with new inline variables declaration when explicit variable declaration may be absent.

    • You don't intented it, but your examples neatly show the problem of such prefix naming conventions 😉

      They mix up things! t_, s_, r_, ... are types but v_ for "plain(?) variable" stands for the changebility compared e.g. with c_ for constants. And what do you mean with "o_ for instance of a class"? I guess an object reference variable, that can point to an object of a class.

      If you really want to use prefix naming convention, you must do it right. Each position of the prefix has to have a defined meaning: e.g. position one is context (l, g), position two is changebility (c, v), position three is type (e, s, t, r, ...) and maybe more. But who wants to have that? But otherwise they're necessarily faulty ...

      B.T.W. I created such a complete ABAP naming convention once, but I won't publish it, because I'm afraid people would start using it ...

      • "Plain" - I mean simple (without structure, e.g. string, numc, etc.), so no mix up.

        Instance of a class -

        Object of class and instance of a class are synonyms.

        Changebility is not nesessary - for constants there's prefix "c_", other that can't be changed is input parameters and it has prefix "it_", "is_" and so on. The more simply is the better.

        If something doesn't keep within these simple rules, most likely the code is written non-optimal.

          • MY first priority will ever be: Solving the problem itself by using a clear, understandable and maintainable Coding. The more rules I have to consider, the more risk to fail there is.

            AND again: Changing the type of a variable results into renaming jam. My time is too expensive for that kind of stuff.

            I wish, a part of the time, wasted in naming rules, would be invested in documentation and commentaction works!

      • Two positions are sufficient, I believe, to create a convention covering at least 95% of "everyday programming" scenarios.

        1st position for scope/context of the use (which already implies changeability); 2nd - for the ty... *err* i mean, the kind of use; where the names defined with reference to ABAP predefined types or DDIC Data Elements require no additional specification at second position.

        With the exception of the wretched "home-cooked" Object Lists or Iterators, which I avoid anyway, and the deliberate vagueness regarding the "kind of use" for data reference variables (lr_data can refer to "simple" data, a structure, table or "worse"...), I find nothing objectionable or even debatable in our convention 🙂

        Pos 1

        Pos 2


        Use with




        Report Parameter



        Report Select-Option



        Importing parameter


        Importing reference to interface


        Exporting parameter


        Exporting reference to data


        Changing parameter


        Changing structure


        Returning parameter


        Returning "simple" data type


        Local variable


        Local table


        Global variable


        Global reference to Object List (Iterator)


        Member variable



        Member variable reference to object


        Static variable

        me-> /  class=> / if=>


        Static variable of "simple" data type



        me-> /  class=> / if=>




        "Simple" data type


        Changing "simple" data type


        Reference to object


        Importing reference to object


        Reference to interface


        Returning reference to interface


        Reference to data


        Local reference to data


        Reference to exception


        Local reference to exception


        Reference to Object List (Iterator)


        Returning reference to Object List (Iterator)




        Global rable




        Local structure


        Flag (Boolean)


        Member variable flag

          • So you don't allow constants in methods? Don't see, how I should name them with your rules.

            And that's what I mean."Simple" rules can never be logical or complete.  Its just something one has to believe in 😈

          • What would be an example of "local constant"? Yes, "local constants" are frowned upon here, to discourage local definition of things that aren't local ... Local interface or local class, if there really is need for them.

    • Unfortunately, you did not disprove one single argument of my blog post. Neither the contradictions or the arguments of famous people, nor any other argument, I posted. Your single "argument" is "more readable", which is very subjective.

      Rules have to be objective.

          • Naming conventions it's the first document you must read when you comming in commercial project as ABAP-developer.

            ISo what? 😕

            Your comment is utterly irrelevant to the argument of whether prefixes are better than not using them, or whether they make code more or less readable.

            In the situation of a sensible company that has figured out that prefixes are bad, in those standards, you'll read something along the lines of "Use meaningful names for variables. Do not use prefixes to denote type". Considerably easier to commit to memory than a bunch of arbitrary naming conventions, surely you'll agree?

            Btw, I've been working in SAP since 1997 in many different places. I've probably written more naming conventions than most developers have read.

          • Are you kidding? No Security Guidelines? No Style Guides? No development process definitions? No test rules? No quality management process definition? No documentation guidelines? They have to read the Naming Conventions with first priority?

            I am also a Data Protection Consultant. I am auditing SAP Systems, as well. And I find one Black Hole after another. I wrote a SAP security article for the most famous german IT professional periodical (called 'iX'), showing the most significant security problems in ABAP.

            Now I can stop wondering about these security issues, I find. It's because the priorities are defined this way, you described.

            I am giving speeches for CIOs and Lead Developers, teaching that software development is an industrial process and they have to define quality management processes for the development process. That they have to document their f*cking SAP system. How important standardized test processes are - not only for the security, but also for the quality of their software.

            Do you realize, that my head is banging my desktop, reading your post, that the naming conventions are SO important? This has nothing to do with professional work, sorry. This is programming for script-kiddies.

            There are masses of developers, lead developers and CIOs, not realizing, that hey are dealing with the most valuable treasure of the company. The SAP system and it's customizing is the code-written whole-company business process definition. And they are dealing with this treasure in the same way like a trashcan.

            (Edited for expansion)

          • Do you have security guidelines for ABAPers? Documentation rules? How much is the percentage of documented development objects? How many pages your testing process rules have?

          • Usualy on a project I readed (If I was as ABAP-developer ore create If I was a ABAP-team leader) one dociment  (I don't know as it's will be in English, if word by word) - "Regulations of ABAP-development". It includes style guide, naming convention, requirements for documentation, development and testing process description, performance and security guide. Usualy BASIS-team was a separated and they gave additional security requirements.

            P.S.: By the way, if I understand correctly, the naming convetion is the part of style guide.

  • Since it's Friday before TechEd - one consulting company has a rule that literals must not be used (such as IF PARVW = 'WE') and must be declared as a constant. Not a bad idea per se, but this results in stuff like 'c_zsomething VALUE 'ZSOMETHING''. And c_zsomething is used in the code exactly once. So far we did not have any cases when 'ZSOMETHING' changed, but I'd be curious if a person making changes would just do  'c_zsomething VALUE 'ZSOMETHING_ELSE''. That would be fun! 🙂

  • I would still say, that a static public attribute of a class is behaving very much like a global variable. Imagine 5 classes with rich logic that are inheriting each other - and some of their attributes are pulic/protected. In such scenario IT IS global variable

    • You WOULD say that? And why you do not say it?

      A public attribute of a class is completely different from global variables:

      A "global" variable is not global, it is only accessible within the program, where it is defined. So it's not global, but local within the program. A public attribute of a global class is accessible in the whole system. That's why I wrote. that the g-prefix is completely wrong, SAP does not know global variables at all!

      An attribute is more than a variable, it has a context - the class. An attribute is a part of the classes' definition, it's a characteristic value, not just a part of the RAM. A variable is not bound to the development object, where it is defined. A VBELN is a VBELN, but an attribute (for instance) SALESDOCUMENT->VBELN is a VBELN of a specific Salesdocument, which is been represented by the object SALESDOCUMENT.

      Because I have to explain that, it seems that you did not understand OO at all. Sorry, but this is the truth, even it is a hard conclusion of your posting.

      • I don't particularly fancy taking part in a heated debate, but IMHO there is some merit to comparing global variables to attributes of a class (public or otherwise).

        Just as global variables are, within the context of a main program in which they're defined, accessible from all subroutines in that same main program, so are attributes of a class (so here the context is the class definition) accessible from all methods of that same class.

        In both cases this is in contrast to local variables that are defined in a specific subroutine of the main program, or in a specific method of the class.

        I won't try to judge how well anyone in this discussion has understood OO (or anything else)...

        Cheers, Fred

        • But, as I said, an attribute has a context (the context of the class, as mentioned), which a variable does not has.

          And (as Dimitri wrote) a static public attribute of a class is accessible from outside this class. This is not possible with "global variables" (that's why they are NOT global, to repeat).

          To compare variables and attributes is like comparing eggs with apples - both are rounded....

      • Only to broaden my outlook: if, as you say,

        "A "global" variable is not global, it is only accessible within the program, where it is defined. So it's not global, but local within the program."

        , how must be calling variables defined in subroutines to distinguish them from local variables of a program?

        • I do not understand your question.

          The usage of variables, you call "global" has to be avoided, because they are valid in the whole program (and, particularly, in all subroutines of that program).

          I don't use that type of variables. Some are un-avoidable (such as selection-screen fields), but I only use them for method calls.

          I'll give you an example. Tell me, why I should use global variables in this coding (which I wrote only for you 😉   -  so I never tried to use it, I only did a syntax check):

          All Coding is placed in LCL_REPORT or LCL_REPORT_EVTHDL:

          (surplus coding deleted)

  • Hi Ralf!

    Great post! Thanks! Keep posting! 😉

    Here is my opinion:

    I also don't use prefix to define identifiers (none of them).

    I don't use prefix to define parameters (of methods or function modules) either. I think they are also useless. Here is what I'm talking about:

    FUNCTION z_calculate_total_amount.
    *"*"Local Interface:
      e_total_amount = i_quantity * i_price.

    When I want to call this FM, I write this code:

        i_quantity     = 12
        i_price        = 199
        e_total_amount = DATA(calculated_total_amount).

    Parameters with prefix "i" are listed under EXPORTING, and the parameter with prefix "e" is listed under IMPORTING. I don't like it. Here the prefix confuses me and makes unnecessary noise.

    Instead, I simply give them meaningful names without any prefix, and then if I need to call them, I trust in Pattern Wizard that will generate me the proper function call, with the proper parameters:

        quantity     = 12
        price        = 199
        total_amount = DATA(calculated_total_amount).

    What do you think?

    One more note. I'm also convinced, we should use as many characters as many we can to define our identifiers in order to make them more meaningful, since we have 30 characters to define them. Here is my post about it: 5 Ways to Improve the Readability of Your ABAP Code


    Warm Regards,

    Alex Gönczy

    • You arme right, nur what would you do, if you develop a FM or method with importing and exporting parameters from the same type? I. e. concersion routines? You can not use the same name twice....

      • In these cases, I usually use identifiers like:

        FUNCTION ...
            VALUE(INPUT) TYPE  ...
            VALUE(OUTPUT) TYPE  ...

        or simply

        FUNCTION ...
            VALUE(OLD_VALUE) TYPE  ...
            VALUE(NEW_VALUE) TYPE  ...

        Warm Regards,


      • Ralf Wenzel wrote:

        You arme right, nur what would you do, if you develop a FM or method with importing and exporting parameters from the same type? I. e. concersion routines? You can not use the same name twice....

        retunring parameter. new_value = convroutine( 15 ). No parameter name needed if there is only one importing.

  • Good post...

    I never thought of this before. Just using the notation because everyone does...

    I think the notation of my next program will be another one. 😉

    • You did not understand the statement. A non-ABAPer does not believe, that ABAPer work with methods of the time before OO was invented. In clear words: "You are working with FORMs? With global variables? Where have you been the last 30 years, ABAPer????"

  • Hi Ralf, a good post you write here. Specially Part 3 is important, or the most important. As I start with ABAP, comming form C#, I allways ask myself “What the hell is lt_kna1”??? Why they are not name it like everybody else “shippingPartners”??? In each other language you have such conventions.

    Form my point of view, the understanding/readability of code is the most important thing. Even more important than performance. Because readability reduces errors and save a lot of time.

    So why no one in ABAP learn that concept of “speaking variable names” ?!?