Hungarian Notation

It has been a while since it was last discussed online, but it has this nasty habbit of returning over and over again: Hungarian Notation.

And I'll admit, my presentation on NavTechDays contains a slide about the subject too.

There are as many opinions as there are developers.

So what is it about, this "Hungarian Notation". Basicaly it's about variable naming. There is even a page on MSDN about the name.

It's called Hungarian Notation because its inventer was a eastern (or central) european guy so his collegues started to call it Hungarian Notation. There, you know it.

The principle is about the value of adding type identifyers to your variables. Something that has been discussed at any Nav Partner probably over and over again.

Examples:

  • boolBusy  : boolean
  • txtInitial  : text
  • cApples   : count of items
  • flagBusy  : boolean (flag)
  • iSize   : integer
  • decPrice  : decimal
  • pFoo   : pointer
  • arrStudents  : array
  • fnFunction  : function name
     

Problem is, in order for this to work, there has to be a standard that everyone in an ecosystem uses.

Whether you like Hungarian Notation or you don't, fact is that Microsoft Dynamics NAV does not have that, so every attempt to introduce it will undoubtly fail, unless you rewrite the base application and never interact with other NAV applications in the ecosystem.

Other problem is, many partners and/or developers do use it, but all with their own way, so the problem gets even worse since code get's moved around and people switch jobs or partenrs swicht systems. AARGL. Stick out tongue

Microsoft has stopped promoting this methodology years ago and Navision has never used it.

Variables used in Dynamics NAV have a tendancy to be self explaining, like Amount, which is most likely to be a decimal right? And CustLedEnt must be a variable of the record Customer Ledger Entry.

When I started programming the company I used to work for used a Data Dictionary which only allowed you to use variable and field names that where in this Dictonary. When you wanted to use something else you needed to request this name at with the DBA guys. Needles to say this was a COBOL system even though I'm only 34 years old. Cool. Not everything in Cobol was bad you know, except waiting 15 minutes to compile if you're lucky. BTW: This company did not use Hungarian Notation either.

Only exception IMHO are extra explaining identifiers that cannot be derived from the self explainingness of the variable, such as Temp or Buffer for a temporary record variable or p for a pointer in a function.

Anyway, I'll pobably cause some reactions since this is, like I said, somthing that has many, many opinions.

So what are my reasons not to believe in Hungarian Notation

  1. We are developing on top of a huge base application that we all share and does not use this notation
  2. We are part of a wide ecosystem of partners that cross-sell each others solutions that get combined with this base application. Our customers expect us to do this in a seemless way that allows ease of maintenance and upgrade
  3. I do believe in the usefullness of Hungarian Notation in some languages but for some reason it does not improve the readability in Dynamcis NAV

Cheers.

This is published in the contents of my presentation at NavTechDays and with regards to the Partner Ready Software project.

Comment List
  • I agree the following statements:

    - our code should be readable and self explaining

    - readable means: you get the meaning and the scope

    We get the type in the status bar but not the scope.

    I would like to discard all variable names ending just with a number like Customer1, Customer2, etc. Even it might be the common metholology I prefer to add a litte suffix to explain the usage. For example if one record is for loop through a set of rows in a table and another record is for treating (like MODIFY) I would name the variables as Customer and CustomerWrite or CustomerLoop and Customer.

    But at the end it is not that important. I'd like more programmers follwing programming methodology like they are mentioned in Robert C. Martin's "Clean Code".

  • I disagree with this article, it is too black and white. See comments above.

    As always there are more sides to the story.

    Let's agree to disagree.

  • I actually do believe in using Hungarian notation in one limited area and that is object names on forms and reports.  If I have a textbox that is for first name, I tend to name it txtFirstName.  This way I can still have a variable named FirstName that stores the value and have no clashes.  Plus it helps text boxes, check boxes, etc. all stand out for me apart from my variables.  I'm sure some of you will want to burn for a heretic, but yes, sometimes I believe Hungarian notation still has a use.

  • I fully agree with you Mark. By the way... great presentations on NAVTechDays, congratulations!

    Wether we like it or not (that's not the point) , we all learn to read standard NAV code... so let's just write similar code and everybody will be able to read it!

    Salut!

    Laura Nicolàs

  • Long time ago there was a doc describing standarts for Navision development, among other definitions (e.g. how custom AppArea table structure should be designed, size and alignment of controls on the Forms) there was a whole chapter about naming issues.

    These rules were rather restrictive - even to the extent of when and where plural or singular noun should be used, and these rules indirectly excluded any use of Hungarian notation.

    BUT - more important was another rule: name everything in ENGLISH! Even if the product will never be used outside the non-English speaking country where it was developed! Non-English naming creates far more mess, than the unwelcome usage of Hungarian notation.

    Couldn't find this doc on the spot, but I recall it was related to AddOns developing/registering docs package...

  • Disagree. There is an advantage in using a different naming standard, than what Microsoft is using in NAV. Otherwise you risk an object merge (like when upgrading to a new version, or adding an add-on) causes strange problems. This happens if you have created a new local variable, but the upgrade adds a new global variable with the same name or vice versa. This can cause unpredictable behaviour, that in worst case isn't noticed during test.

    I therefore recommend using a different naming standard, and preferbly a standard that actually adds value when working with the code. I agree that you very rarely are in doubt about the variable type, so Hungarian isn't my favorit choice. I prefer a standard indicating if the variable is global, local, parameter or a return-value. This is not shown in the status bar in the C/AL editor in NAV, unlike the variable type. My current company is therefore prefixing all our variables with g_ l_ p_ or r_. Works like a charm, and has even caused developers to be better at making local variables :-)

  • Some people though just can not be taught.

  • "For me in a job interview I ask a developer to write some NAV code, if they use Hungarian notation, I never call them again."

    Can you send that developer to me .. I'll just learn him decent coding ;°)

  • Hungarian notation has no place in Navision. The only one thing it does is makes it more expensive to maintain the code, thus the customer pays more money to the partner. NO OTHER USE.

    For me in a job interview I ask a developer to write some NAV code, if they use Hungarian notation, I never call them again.

    Standards are there for a reason, they are to reduce the cost of the system.

    Very good post Mark. I am with you 100%.

  • Fully agree with your arguments, Marq.

    Cu in Antwerp ;-)

  • AS Hungarian I would argue of being Eastern European ...

    Lets call us Central European :)

    Gabor Faludi

    www.fits.hu/navblog

Related
Recommended