Blog

Code is boring. It is geeky. And it’s ugly, too. In C/AL it is especially ugly. While contemporary development tools come with all sort of gizmos which make coding easier, such as color-coding, auto-completion, refactoring, etc., C/AL editor seems like having awaken from a thousand-year sleep. Take a look at the color coding: there is none. Or there is, but palette is limited to that of Charlie Chaplin’s. There is some functionality which looks like auto-completion but it is not, and the text editing capabilities make you dream about Notepad at night. But you can look at it from a different angle. C/AL editor is the way it is for a reason: to keep programmers away. It’s the defence mechanism developed over twenty or so years of evolution of the system, to protect the system from rookie knowitall programmers ripping away that stupid Gen. Jnl.-Post Line codeunit and rewrite it the way it should be. With this, we come to Rule No. 1: Know what you are doing.

In Microsoft Dynamics NAV, it is so easy to jump into code, rewrite it, add something, take something away, and make the system behave the way you want it to. If it is only so easy to make any customization, you need to consider many things before you make even the slightest change. Things such as what kind of effect the change will have on the existing code, what kind of change will it have on the way future changes have to be made. Let’s have a look at an example.

You write a function which accepts a text parameter of length 30, passed by reference (Var), and you call this function from ten different places in ten different situations. A new situation occurs, when you need to pass a text variable which is longer than 30 characters, so in order to accomodate for this new situation, you extend the length of the parameter to 50. At the first glance, this simple change can introduce no regression problem: you extended the length of the parameter, therefore if won’t affect any of previous 10 situations which pass 30-character variables, if it worked when it was 30, it must work also now when it is 50, right? Wrong. The length of textual parameter passed by reference is determined always by the length of the passed variable, not by the declared length of the parameter, so for original ten situations the parameter length within this function will be 30, and it will be 50 only for the new situation which passes a 50-character text variable. At the very point of the change, probably nothing will go wrong, but tomorrow another developer may come to do some change to this function, see that the parameter length is 50, and depend on it to make a modification in the function, which will cause all previous ten situations to result in a text overflow error. In order to properly extend this function to accept a 50-character parameter in the first place, the developer must extend all variables ever passed to this function to 50 characters, otherwise this innocent change may open a whole can of worms, and in the future cause regression problems all over the place. Whenever you are changing a piece of code, make sure you know all the implications of the change.

Sometimes, your intent is perfectly clear to you, and your code also works perfectly. But you are not going to always be in charge of your code. Someone else may come and want to change something, which brings us to Rule No. 2: Make sure others will know what you did.

This is just a simple illustration, but have you ever seen code like this:

<span style="background-color:#dddddd;">GetCFromBTCNo(VAR c : Code[20])</span>
IF c <> '' THEN BEGIN
d.SETRANGE("No.",c);
IF d.FIND('-') THEN BEGIN
e.SETRANGE("No.",c);
IF e.FIND('-') THEN BEGIN
c := e."Bill-to Customer No.";
END ELSE BEGIN
c := d."Bill-to Customer No.";
END;
END ELSE BEGIN
c := '';
END;
END;
f.RUN();

Not only it is formatted badly, you also can’t tell what’s going on just by looking at the code. What is c, what are d, e and f? Are you sure? While you can tell that d and e are obviously records, what the hell is f? It can be a form, a report, a dataport, a codeunit, and before you fully understand this code there might be quite some roundtrips to locals and globals views. I’ve heared hardcore programmers say that if it was hard to write, it should be hard to understand, but opposite is true.

Joe Celko once said that whenever you are writing code, write it as if someone else will have to maintain it and their last name is Gotti, and they know your home address. This is so true that every single developer out there should print it in Haettenschweiller 72 and stick it to their walls. For a computer, it doesn’t matter whether your code looks like, what variable naming convention, if any, you use, whether or not you use abstraction, whether you write procedurally or sequentially – for a computer it doesn’t make any difference whatsoever. But no single line of code is ever written for computer only. People get in touch with code, and they get in touch with other people’s code too. Don’t make them hate you.

At this point I wanted to introduce Rule No. 3: Preserve the environment, and discuss the effect your changes have on surrounding code, mostly from upgrade perspective, but it is both too late and too complicated to put it just into a few words, so I postpone it until the next time, and leave you in anticipation 🙂

See ya!