Tag Archives: C/AL

Code of coding 4: Die, hard(coding) 2

In Croatia, most of roads resemble battlefields. They are so full of holes and patches from all kinds of repairs over time, that they have to re-pave them every five years or so. It is an awful waste of taxpayer’s money, and makes you wish for the world of Jennifer Government to come be. Anyway, as soon as they re-pave the roads, not a week usually passes before they come again, with jackhammers and heavy machinery of all sorts, and start drilling away, blocking the road in process and causing mass-frustration, just because some wacko has suddenly remembered that it would be nice idea to pass the optic cable underneath, or some valve started leaking.

Continue reading Code of coding 4: Die, hard(coding) 2

Code of coding 3: Die, hard(coding)!

Development is an important phase of implementation of a highly-customizable ERP system, such as Microsoft Dynamics NAV, and that’s why I put a lot of emphasis on development, specifically on coding part of it. I’ve tried to cover a few do’s and don’ts of coding, but so far I’ve left one of my favorite clay pigeons out: hardcoding.

If you want me to define hardcoding, I’d probably put it something like this: hardcoding is the ugliest possible form of laziness, incompetence, ignorance, indifference, carelessness, or any combination of the five, which in short-term makes my toenails curl up, and long-term leads to poor and unmaintainable systems and unhappy customers.

Continue reading Code of coding 3: Die, hard(coding)!

Code of coding 2: Documenting changes

Few days ago, when I wrote about coding, I didn’t have a slightest idea that at the same time, at the completely opposite part of the globe, Dave was blogging almost about the same thing. It is interesting to know that I am not the only one out there actually worying about code, and how it looks like.

The most common thing I used to hear when I asked bad coders about their code was: “It works, why shoud I care.”

Continue reading Code of coding 2: Documenting changes

Code of coding

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.

Continue reading Code of coding

Convergence

It has been a while since I was here, and I will not try to make any excuses. I could say that I have been busy (which would be true), and that I have a family that I love spending my time with (which would also be true), but true reason is the one you all know: I have been lazy.

Last time I promised to say a word or two about convergence once. Let me do it this once.

Continue reading Convergence