Coding Standards

Hi All,

I wanted to raise a topic here and get the community view. How do you code? I attempt to stick to the MS Standard as much as possible, in defining variable names etc…

Now I’ve been coding Nav for 9 years odd now so I’ve seen many different ways to code. As far as I was aware solution centers “should” stick to the Nav standard, which is contained in a PDF file.

So for example I would declare a variable for the Sale Header record as :


But I’ve seen the Hungarian notation used more and more which would be :


I’ve seen an ISV product that has Hungarina Notation as the code, which was a shock to me as the product was/is endursoded by Microsoft.

I thought in the endorsing that Microsoft agreed the product was up to Microsoft’s standards, and Microsoft does not code in Hungarian.

So I am interested in a debate on this, Hungarian or Not, whats the benefits, does it really go against MS standards?


I don’t like Hungarian, for 2 reasons:

1 - I don’t need a prefix telling me that SalesHeader is a rec variable or that the control variable in a FOR EACH loop is an Integer. Most of the time the code is self explanatory, that’s why you should use actual names for variables. The prefixes that I do use are ‘loc’ for locals, and ‘par’ for parameters

2 - I always check data types in the Globals and Locals list anyway, just to make sure. I don’t trust other developers to do it right [;)]

Other than that I usually try to follow ‘standard NAV’, even though that’s a bit of a fuzzy concept. Really though, as long as you use reasonably easy to read variable names, it is all ok. It is helpful to have one standard when working in one team.

Much more important than how you name variables is to properly comment and document your work.

Very good topic to raise.

Same as you, I try to stick to the standards. If someone else picks it up. Its easy for them to understand.

As far as naming conventions go. I dont like the recSalesHeader (it just doesn’t feel right to me). But there are worse things. For example using SH or something completely different to the table name.

Yes, nice topic.

I try to adjust my code to the NAV way but maybe you’ll ban me from the forum when you’ll read this… when I began with this a year ago I didn’t really read the manuals, so now I still have code in my objects calling a rec var, for example SalesHeader (table 36), as rec36 … oooohhhhh !!!.


In a couple of years I have seen a lot of different notations. Some companies I work/worked with have even big manuals for their employees how to program according to THEIR NAV standard (variable names, number ranges for project and area (G/L, Sales, Purchasing, … specific objects…). In my opinion this makes sense to produce synergy within that partner. You have to adopt, working for different clients, especially if you have repeating business with different partners that have different rules, but HEY, this is what I get money for.
If I have the free choice I use appendixes like SalesHeaderL, SalesHeaderP, SalesHeaderG for locals, globals or parameters…

I agree that it makes work easier if everyone on the team uses the same structures. Your eyes become used to certain patterns, so in my case I would expect the local/global designator to be a prefix, so I would potentially have a harder time recognizing a suffix because it’s not where I would expect it. So when you join a team, make sure you are aware of their standards and try to stick to them as much as possible.

I’ve never thought about using prefix or sufix, but I think prefix is a good way to visually clasificate vars when you’re using Symbol Menu. It’s sometimes a little chaos to use !!.

In my case I didn’t join a team, I’m just the team jajaja so I should define my standards for future partner’s developers. I will use when possible NAV standards but… don’t you think it’s too complicated the standard for comments in NAV?, it’s ok for add-ons but, at least in my company, where are modifying objects every day, I’m exasperated…

I think i like the idea of have prefix like recSaleHeader being record variable, gvarSaleHeader being a global etc. this can tell the developer the type of variables they are instead of going all the way to view-. globalvariable to verify. In my company we don’t have any standard way of developing but i think is high time now we adopt a standard.

Couldn’t agree more.