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.
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.
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. . 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
This is published in the contents of my presentation at NavTechDays and with regards to the Partner Ready Software project.
Only three nights sleep and we'll celebrate 12 years of www.mibuso.com. At least that was what we did 2 years ago, celebrate 10 years of mibuso. But this time its more. Much more.
With two days, 450 participants and 13 great sessions it will be bigger than ever. And this time I'll participate in the contents of the event. First with the Partner-ready Software session that is hosted by Gary and Waldo. I'll do a small contribution there.
Partner-ready Software is a new concept of developing "add-on" solutions in Microsoft Dynamics NAV that is the "Brain Child" of Gary Winter, a very good NAV friend that I met 10 years ago and also became a personal friend. PRS is supported by by Lars Hammer (MS Principal Software Architect) and the Microsoft EMEA product team.
PRS is to much to be covered in just 90 minutes but we'll try. I'll stop teasing you now.
Then I'll do my "own" session about Tools & tricks that make NAV development easier and more organized. That session will have to compete with Data Visualisation by Christian Abeln so I hope to have at least one or two people in my room.
So. Hope to see you there, and if not than maybe at Directions USA in two weeks from now.