As a NAV developer there are basically only 2 books to live by:
- Application Designers Guide
(Also available in the F1 Online Help in the application) - C/AL Programming Guide
(Programming-, Naming-, Numbering-conventions in NAV)
These books should be mandatory reading by any developer/person doing development, but real world experience unfortunately shows they aren’t. Even for ISV products you see some scary interesting examples.
So in case you haven’t seen this before, here they are. Fortunately some of the new Dynamics NAV books cover these basic principles too, especially on how naming conventions are in NAV:
“Precise and consistent terminology helps the end user work with the application. Rules for naming and abbreviating everything will also help programmers gain an understanding of the base application and develop new features faster.”
So no need for using prefixes for your variables eg.:
recCustomer
l_Customer
g_Customer
when you just can use: Customer
[dm]9[/dm]
[dm]8[/dm]
Other books on Amazon:
Implementing Microsoft Dynamics NAV 2009
Programming Microsoft Dynamics NAV 2009
Microsoft Dynamics NAV 2009 Application Design
Programming Microsoft Dynamics NAV
The NAV/SQL Performance Field Guide
‘…So no need for using prefixes for your variables eg.:…when you just can use: Customer’
How would you then call variables referring to table 3 (Payment Terms) and standard form 4 (Payment Terms) if you need to declare and use them both in one place ? 🙂
According the the C/AL Programming Guide:
“When a variable is of the object type (Record, Form, Report, Dataport or Codeunit)
and the object has a name that also functions as a field name or local function name,
you can give the variable name the suffix Rec, Form, Report, Dataport or Codeunit.
EXAMPLE
VAR
SourceCodeRec : Record “Source Code”;
SourceCode : Code(10);
Since “Source Code” is the name of a table as well as the name of a field in other
tables, using the name “SourceCode” for variables holding the two different kinds of
information would be confusing.”
Yep, simple Customer is quite often not enough, so I would rather suggest to always use “Rec” suffix in variable name when variable refers to table. Even if there is no other objects or field sharing name. At least the code is consistent then.
Personally I am also using bit more differentiated naming convention. Not in accordance with Application Designers Guide but makes codes much more readable:
The rules are quite simple – all global variable names start with g (so gCustomerRec for example), all names of variables passed as parameters start with p (pCustomerRec for example), all table variables declared as temporary starts or include “Temp” in their names (so gTempCustomerRec, or just TempCustomerRec in case of local variable) and all text constant names meaningful and written in capitals (so BAD_CUSTOMER_NO rather than Text0010 for example)
Reading the title I’ve had an impression that you address ‘spaghetti’ coding style. Too bad you didn’t.
Slawek –
I dissagree with you saying that recCustomer is easier to read.
for YOU reading YOUR code; Maybe –
For ME reading YOUR code – absolutely not!
A co-worker (an mentor) once had me write a report in the good old blue version of Navision (Navigator). I had created a cool requests form, and proubly showed my co-worker.
Here’s the conversation we had:
[quote]
ME: See, and look – if I select this, this stuff shows up.
Him: That’s cool… So where in Standard Navision did you copy this from?
Me: Nowhere
Him: If we don’t do it in Standard Navision – We don’t do it either!
[/quote]
The point is, that it should be transparent what’s Standard and Non-Standard code. The same goes for behind the scene. I can scan standard code pretty fast, but my brain slows down, when I have READ the code.
It’s almost like reading traffic signs – NO RIGHT TURN ON RED – a common traffic sign – NO PARKING is an other –
What would happen, if a city decides to have them say RIGHT TURN ON GREEN ONLY and another YOU ARE NOT ALLOWED TO TURN RIGHT WHEN THE LIGHT IS RED and a third city introduces YOU CAN’T PARK HERE.
the Key word here is STANDARDs – Just like other industries have standards that help it.
That’s my 2 cents
“I dissagree with you saying that recCustomer is easier to read.”
I agree with you disagreeing with me that recCustomer ie easier to read, mostly because I’ve never said this.
“It’s almost like reading traffic signs – NO RIGHT TURN ON RED – a common traffic sign”
Have you ever seen small green arrow poiting right below red sign ? Most probably not. It tells you – yes you can turn right on red if you carefuly check that no one is approaching. Did you miss that because you can read only ‘common’ traffic signs ?
You are free to chose better/more easy to understand coding style or blindly copying everything what Microsoft put into NAV code. Will you write your module in one 30 pages long funcion – like Post() in CU80 to follow MS coding style, or rather split your code into small, meaningful and easy to understand (by you and what more important OTHERS) functions ?
After all – if you dig a big more you will be able different places with different coding styles in standard NAV quite easilly …
And at last – no offence – but if your brain slows down reading CustomerRec to get the meaning then…hmm.. not all of us have to be developers..
The title was more meant as a reference to the developers holy book, and trying not to forget any or insult others, i used the reference to: http://en.wikipedia.org/wiki/Flying_Spaghetti_Monster 🙂
Didn’t know this Flying Spaghetti Monster case :). Gooood one indeed 🙂
OK, as the co-author of one of the books that heavily advocates the use of l_ and g_ as the start of variable namings, let me give the reasons why.
1) It makes it easier for me to find the variable definitions since you need to call up different windows to view local and global variables, it helps to know which it is before you open the window.
2) It totally eliminates errors where the same variable name exists as a field on the currently inscope table, a local variable and a global variable. I have seen many instances where a programmer thinks they are using one variable and the compiler has different ideas.
I’ve had long discussions with people about this who say that we must religously follow Microsoft’s standards for programming C/AL, but Microsoft also says (I have heard second hand) you should not include comments in your code, which in my mind is crazy. When I write code, I try to eliminate common errors and make it easy for others to maintain. I think this is more important than making my code look like Microsoft’s. Do you find the standard application code easy to follow and easy to maintain?
I definitely do see the point of marking the variables with a prefix. As long as you keep your naming conventions in sync with the guides the code can still be readable – and yes you have the advantage of knowing the scope without looking it up.
But in most (if not all!) programming languages, your variables should have the smaller scope possible. One main argument is with the increased scope you have more code that potentially could modify the variable, adding more complexity to the solution. So the question when using a global variable should always be: “Is it necessary?”
Reading the CAL Programming guide, will without doubt be a great starting point for any developer. As you can read on the user forums a lot of new junior developers are just being thrown in to projects without any preparation of any kind.
I can only agree 100% that this is ugly and wrong. If your memory is too short to remember from the Variable List to the code can you keep the window open on the side.
I have seen this apear in the code for some reason. I do not know who has started to advocate this. But it is useless information to see in each and every variable parameter or similar. The Naming convention should be as in the Green bible matching the base product. Until another set of guidelines and style is implemented in the base code should everything else follow those standards.
By inventing your own style is you clearly communicating to everybody that this is not the base product. In my mind a big warning sign pops up. How is this helping other people when not following the guidelines.
I do not think code with “_” looks good either. maybe technical and sofisticated, intended to confuse people, but not necessary when you have guides about to use the same abbreviation and naming conventions.
Customer Ledger Entry = CustomerLedgerEntry or CustLedgEntry