F5 Fumbles Find Fat-fingered Frustration

Let's face it the C/AL editor is a dog. And I don't mean the "man's best friend" type of dog. I mean the type of dog that chews your slippers and pees on your carpet. The only improvements I have seen over the last 6 years are the ability to find functions using the search command and the new version 5.0 ability to indent and outdent blocks of code using the tab key.

Visual Studio programmers may have difficulty reading now as their eyes are filled with tears of laughter. Vjeko has some interesting theories as to why the C/AL editor is so bad. I wish I knew why the IDE takes a back seat for the Dynamics NAV team. Even the much-anticipated NAV "6.0" uses the same development tools (as far as I can tell from the screen shots.)

Today for the first time I realised how crazy it is to put the most useful key for C/AL developers (the F5 key which brings up a kind of poor-man's intellisense) right next to the killer F4 key which is used to delete the current line of code with no prompt or undo. Thanks for that! Save your work frequently or be very careful when reaching for the F5 key.

So what can we do to help ourselves since improving the development tools does not appear high on the list of proposed new features?

I have found my life easier since starting to use a variable naming convention that identifies if a variable is a parameter, local or global. I know this is pretty radical and against the standard programming conventions (something that should not be necessary if the IDE provided good visual cues for the developer.) For me it's simple. I put p_ in front of my parameters, g_ in front of my globals and l_ in front of my locals and I then find it so much easier to follow my code. Programming logic errors of using a local variable by mistake when you meant to use the global variable of the same name disappear in an instant.

The other thing which the NAV coders don't seem to be big on, which I find very important, is to write code for people not computers (something Vjeko has also written about) which I recently re-discovered when flicking through my old copy of Steve McConnell's excellent book "Code Complete."

Steve talks about writing "self documenting" code through the use of good function and variable names and clarity in preference to efficiency. For me the most important thing is to comment the intent of the code. How many times have you struggled to find a solution to a buggy piece of code because it is not really clear what the original programmer intended the code to do? Steve talks about designing your code in PDL (Program Design Language) which seems to be a kind of Pseudo-Code. He says it is a good idea to make you program with the PDL as comments and then fill in the code around the comments. Hey presto! You now have commented code with "headlines" of comments that can be read to illustrate the intent and purpose of the code without forcing the hapless support engineer to decipher your code.

Avoid smart programming that is just hard to follow. I recently had to go through the 3.70 to 5.00 upgrade codeunit and I was really struggling to understand why the main update routine was called twice with a slightly changed variable until I realised that the first time was just to count how many records we needed to process so we could display a progress indicator. Now this may be common practice for NAV upgrade routines but to me it was a frustrating waste of my time to have to figure this out. If two different functions had been used with names like CountRecordsForUpdate() and UpdateRecords() then I would not have had to spend time understanding what was going on.

So I would change Vjeko's rule number 2 from...

Rule No. 2: Make sure others will know what you did.

to...

Rule No. 2: Make sure others will know what you intended to do.

Dynamics NAV IDE team - I think it's time you surveyed your partners to get a list of features they want in their Dev tools for C/AL.

Dynamics NAV Application Developers - I think you need to use comments and write code that is easier to follow.

Now it's time for me to get back to my C/AL editor. Here boy!