Code writing standard

BHT

Hi there,
I'm curious to the code writing standard in version 5 (and above including hotfix).
Some codes written didn't follow NAV standard as in my training I knew (or in terminology).
The way they define the variable, code writing indentation, etc seems made not by NAV developer.
What is happening to the development team :?: :?: :?: :-k

idiot

Hasn't it always been this way?

garak

Yes thats true ....... there are new "Newbies"

Also some forms are not in "design standard"

BHT

So... all of you feel the same feeling...
Does it mean Microsoft doesn't care anymore? This never happen before Microsof acquisition.

Eugene

i haven't looked much into it but to my mind most crucial thing is to split user interface from data processing
think about having multiple interfaces (e.g. standard navision user interface and web browser interface) to perform the same tasks. As to naming functions variables and lining up code it does not matter that much.

kine

For me there was never something like NAV standard. There were only NAV way or something what was described in manual, but this is not "standard".

David_Singleton

It wasn't really Microsoft.

Up to version 2.01 the code was pretty consistent. And the look and feel was generally kept. The biggest changes really came with AD and Manufacturing. These were both Add-ons that really didn't follow NAV guidelines 100%, and once they were merged, the standards got a bit slack. Of course then came the Mother of all disasters that we now know as Dimensions. So once 3.01 was released, the "Navision way" was a thing of the past. By the time MS bought NAV, the damage was already done.

Now new developers seem to get into MS and look at bits of code and don't see why they need to follow standards when the last person didn't.

Many people say this is not important, but I would ask them to make a simple Mod, like add Variant code to a production order, or exclude Open orders from planning, (things that should be 30 minute mods, and now take many hours instead).

Unfortunately there is no one or no group with a vested interest in fixing this, so I can't see it changing.

TonyH

Coding standards is one of my pet Peev's. I learnt to code Nav pre-MS, so like to think that I was taught before the waters got murky.

One thing I've noticed in NA is that the "Approved" add-ons are nowhere near the coding standards I would expect. Things like "Hungarian" notation. This was invented for older development languages where by you did not have easy reference to what a variable was, This is not really the case in Nav development (cursor on variable, look at status bar).

Another poor example would be an approved add on I saw here in NA, and I will not say who or what for fear of slander, but the developer HARDCODED a setrange with a unit of measure code of 'HR'. Seriously?

I think MS should be harder on their own staff about coding standards, and should also be hard on ISV's. I mean they do put their name to the products!

T

jlandeen

As far as Hungarian Notation goes I definately prefer to see it in Navision code (yes you can look at the status bar) but I find in general it helps make the code a lot easier to follow. It may not be as understandable to the laymen going in there - but then again I don't know if I would trust any old business analayst or random person to modify Navision code.

I think standards are great, but the development environment can make up for some of those (why do we need to load everything into the developers tool kit to access a "Where Used' functionality!) - and right now the Dev environment in NAV SUCKS...a move towards .Net can't come soon enough!

The way I look at it it's not Microsoft (or anyone elses fault) that NAV code is moving away from standards. As I see it the code is somewhat open source - you get your Nav Development certification & a dev license & you're allowed to make changes, build add-ons. Navision is growing in popularity and now there is a real push to get developers trained up and rolling as fast as possible and to meet as much of that demand as possible. This means that more & more developers who come from different training & backgrounds will be expected to make modifications, which further reduces the chances of standards staying in place. I think the most important things that Add Ons & New Base Nav Code is that the code is tested, is as modular as possible and maybe even has some inline comments. Even greater still would be getting rid of some of the spagehetti code in some of the posting codeunits would help too...but I don't see that happening any time soon.

TonyH

I do actually have the C/AL Programming Guide from 2002 if anyone wants me to upload that, it does give details on the standards that should be used for Coding within Navision Financials, or Attain as it was when this was released. Yes it is an A/S Document.

Let me know if anyone is interested in seeing it and I will upload it.

T

DenSter

jlandeen wrote:

I find in general it helps make the code a lot easier to follow

I can't tell you how much I disagree with that.... hungarian notation does absolutely NOTHING to make the code more readable, in fact it only confuses people more. You have a page full of C/AL code with 'grec' and 'gint' variables, who the hell can keep those apart?

Besides, are you going to trust someone else's variable names? I've seen so many times something like 'grecInvoiceLine' actually be a local variable into the Item Ledger Entry table, filtered on invoice type, and even worse than that. I ALWAYS check scope and names of ALL variables, regardless of what they are called. Those prefixes are for show only, they mean absolutely nothing.

There, glad to get that off my chest

DenSter

David Singleton wrote:

Unfortunately there is no one or no group with a vested interest in fixing this, so I can't see it changing.

I think it's more a matter of priorities. I'm sure that there are people in the NAV team that care about whether code is up to standards, I just don't think that the budget is there to do Q&A at that level.

You know when budget gets tighter, first thing to go is manuals and other documentation, next is code Q&A. Judging by the types of bugs slip through sometimes you even wonder about the level of regular testing. And I don't say that because I think the product is crap, I just think that attitudes towards software quality in general have gone down. It has become much more common to release software knowing it's not perfect, trusting that bugs will turn up through support channels. I think in the end a lot of money is saved up front, unfortunately at a quality cost.

jlandeen

This is what I was trying to get at with the limitations of the development environment. When I'm working on code in .Net it's very easy to find out those details of a variable (scope, type, contents, where used etc). However NAV makes it more difficult so thats why I find the Hungarian notation useful - if it's used properly.

When you get down to it - that's just another standard that people use. Some like it some don't and there are reasons & arguments for both sides. There should be a coding standard but to find one that everyone likes, agrees with and will work across all of the NAV developers could be difficult given the already mentioned constraints of time & budget.

David_Singleton

The single purpose of a standard is to make sure everyone does something the same way. The standard in NAV naming conventions is defined in the style guide and DOES NOT use Hungarian notation. Thus it is NOT standard, QED and end of discussion. \:D/


The rules of chess make no sense, but since we all have one set of rules, we can all play the same game.

jlandeen

If that were clearly the end of discussion this would be a completely pointless forum post and it would never have been put up here! Yes there is a style guide and it serves as a standard does not mean that it's the ONLY standard in the world.

Clearly there are competing standards & formats that developers are following (for various reasons) and so I think there does need to be discussion on coding standards. Maybe even a way to challenge and change those standards.

Alex_Chow

If you use standards that's different than how the rest of the system reads, then it's possible that you're creating more confusion down the the line for other programmers.

This may be good for your job security. But bad for the greater good.

DenSter

jlandeen wrote:

<snip>
Yes there is a style guide and it serves as a standard does not mean that it's the ONLY standard in the world.
<snip>

I get confused by this type of logic....

One one hand you're making a case that we should all follow "a standard", as long as we all use the same one. On the other hand, you are making a case to use a different standard than the one used in NAV development. By using hungarian notation for custom development, in contrast to existing standards, you are introducing a double standard.

By using a different standard, you are deviating from the standard, and thereby entering the very confusion that you argue we should all avoid. That just doesn't make sense to me. Apparently you feel that the standard that YOU use would be a "better" standard, not just a "different" standard. What doesn't make sense to me, is that in your argument, you say there are no better standards, just different standards (paraphrasing and interpreting here 8) ).

If all standards are created equally, then there would be no problem just using the standard coding practices in C/AL development. They are really not all that hard to follow. Instead, there's not an implementation where I don't see some attempt at rewriting existing code to adhere to someone's idea of a "better" standard.

By the way, what the hell makes hungarian notation so special, just because .NET developers use it? I think it looks like crap, in every programming language, it confuses the hell out of me. It is VERY easy to find out the data type and scope of variables, even in C/SIDE, WTF do we need those prefixes for anyway? It's redundant! Clutter!

This discussion, by the way, is best enjoyed over a glass of ice cold beer and some spicy chicken wings Will you be at Directions again this year?

kine

There is only one point on the hungarian notation I can see (because someone forced me to use it in our company, I must to use it... :-() - you do not need to solve naming problem when you have one global var with some purpose with clear name (like ItemLedgerEntry) and you have function which pass same variable which must be assigned to this global one. With hungarian notation you have something like "greItemLedgerEntry" and "ireItemLedgerEntry", but without you have just two variables with name "ItemLedgerEntry" and this conflict will each developer solve in different way (adding suffixes, prefixes etc.). It means that hungarian notation is wider "standard" than NAV guidelinses, but may be I just missed some point where this sort of conflicts are described and solved.

For me main point is, that each company must use one standard, not that each developer use different style/standard like we can see now in the new code...

jlandeen

wow...yes this did foster a lot more discussion then I had anticipated. My main point with the "ONLY Standard" comment is that there are many cases in programming and the outside world where there are competing standards (North America uses NTSC to broadcast TV, Europe uses PAL).

I do agree on it best being solved over cold beer at Directions!

BHT

Hm....
I agree with all of you people. Pro & cons may always follow to any issues in this world.
I remember when people from NAV A/S give me training they mention to have acknowledgement for vertical product we develop, the writing standard must apply to what NAV built.
I think that is why A/S release guidance as in 2002 programming guide.
I found during those period until version 3.01 as David mention reading NAV code is more easy and interesting than today. Now even the grouping of lines under begin - end is very ugly and look unprofessional. But that is just only ugly example. You can name the other.

I just wonder, when other industry implementing ISO and other standardization format, NAV removing the standard instead.
I believe if there is no standard in this world there may not be any name like Ferrary nor McLarren in this world.