Coding

With .NET Interoperability around, it’s very likely you’ll be synchronously calling external web services from C/AL, to exchange data. I won’t go into discussing whether or not this kind of architecture is good (my own position is that it isn’t), you may end up having situations where your C/AL code simply makes a synchronous call to external systems, such as web services.

Design is one of a kind. Other phases in Sure Step are understood and accepted as good and necessary. But design, do we really do that? Is it really necessary? Who’s going to pay for it? Does the customer really need all those documents? Instead of writing documents, you could have it developed in the same, or less time.

“Best practices” is one of those beloved and hated concepts. There are people who just embrace “best” practices for the sake of their bestness . And there are people who just shun them for the very same reason—those know-it-alls who have opinion on everything and know it better before even learning about it.

Hint: this is a post for developers, and mostly junior developers, those who are still learning how to code properly. I know, I promised not to blog about stuff like this, but I simply couldn’t help this time. A friend of mine has asked me for help. “There is this C/AL function I had to rewrite, now I end up with 106 BEGINs, and only 105 ENDs.

WinDays 2008 are over. Somehow, this conference has become a milestone, in Croatian ICT community, in Microsoft community, even in my life. I met a friend there, one of those I only meet there, and realized just how quickly the year turned. Obviously, I contemplated too much, and partied too little, something to really get worried about.

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.

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.

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.

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.