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.
Officially, definition of hardcoding would probably go somewhat like this: hardcoding is a practice of embedding settings into code.
There are two basic types of hardcoding: hardcoded output, and hardcoded input. Let’s investigate both.
Hardcoded output is when code or UI design in charge of displaying text, does so from the direct entry, instead from a central repository of texts. From perspective of Microsoft Dynamics NAV, typical example of hardcoded output is when UI elements and output messages are unaware of the system built-in capability to handle multiple languages simultaneously. A simple example would go like this:
ERROR('Dokument morate lansirati prije knjiženja.');
There are three basic problems with this line of code. For starters, I bet my kidneys that, unless you are from Croatia, you probably don’t have a clue what it means. A premise of a multi-language environment is that it should enable users to work efficiently regardless of their spoken language. The system should take care of user’s language of choice and automatically translate any output to that language. Well, the system can’t do it if a programmer does something like in the example above. The system doesn’t just know how to translate Croatian into English, or any other language for that matter. There is a mechanism which allows it to do so, and that simple mechanism wasn’t employed in this case.
Many a time I heard programmers complain that the system isn’t going to be used by anyone not speaking Croatian (or any other single language used for hardcoded texts) anyway, and that employing multi-language features would be waste of time and effort, so what the hell, why not simply hardcode the output text message? Because of the fact that the company may hire a foreigner, may be audited by a foreign auditor, may grow outside the national borders, and suddenly there is a need to have the true multi-lingual system. In any of these cases translation of the system will be somewhere at the experience level of Spanish inquisition. But regardless of multi-language feature this approach stinks anyway. Read on.
The second reason why the line above sucks is that it creates a very unmaintainable code in many ways. For example, your code grows (and code usually does), and there is another situation in which you need to display the same message. So you just go and copy/paste, big deal. Then you do it third time, then fourth… Then you end up with four different messages, which are really one. Then you decide to change the message, and change it once, forgetting about other three places. Or at best you need to do a search/replace. Which again wastes time, and might introduce error or inconsistency.
Third reason I will explain after I translate this error to English:
ERROR('The document must be released before posting.');
Now, does this stink, or does this stink? There are much better ways of achieving this functionality (such as TESTFIELD), instead of this one, which is both hardcoding and writing non-standard code. I’ve just made a note in my to-do list, to rant about non-standard coding techniques in the future, but for now, let’s stay tuned to hardcoding topic. It is hardcoding because it overrides the standard behavior which is consistent throughout the system, and replaces it with a fixed behavior which will stand out like a burger in deep space in case a future version of the system modifies the standard way how checking of field-level preconditions works. If anything has a potential to confuse and frustrate end-users, an inconsistent user interface does. Microsoft Dynamics NAV has an as-consistent-as-it-gets user interface, which makes for happy users by default, and “solutions” such as this one are on their best way to introduce unhappiness.
At this, I rest my case for today, this took me much more than I expected, so I’ll serve it in digestible chunks. My next post is going to be about hardcoded input, and it is something which is really bad, but not a bit less common than hardcoded output. See you later!
I must admit that I am an ugly, lazy, incompetent, ignorant, indifferent, careless individual. Or at least I used to be. I was guilty of this for most of the reasons you gave and I got reprimanded by better and more experienced developers.
My argument in favour of my code-abuse was that using a Text Constant (did you mention that?) makes the code harder to follow. I added to my argument by saying that AX allows the text label to appear within the code but provides a hyperlink-type feature to define the multi-languageness of the text.
But, I have to admit that you, and the other smarter, better-looking more careful, developers were right. I should use the standard conventions. When I learnt that if I clicked on the Text Constant with my left mouse button I could see the contents of the text label in the status bar I didn’t see it as such a drawback (it was the need to bring up the Text Constants window just to understand what the code was doing that really bugged me). Who knows maybe the NAV product team will add the feature to display the message in-line in the code just like in AX. If that happened – my code would look pretty silly compared the standard that would simply “inherit” the new feature.
Hardcoding is of course a very bad practice when it is “embedding settings into code” as you nicely define it. However; I tend to disagree about your example and would like to comment each of your arguments:
1) I’ll guess that way more than 95% of the code written by NAV developers are to be used solely in the country or countries the developer already expect. In the few situations where a solution is to be expanded to additional countries it will always require new analysis and development and translation, and changing hardcoded constants into text-constants is the least of problems.
2) You mention the risk of copying the error message to several places and the updating some, but not all, at a later point. The problem could just as well happen when using text constants. An error message needs to be updated, and the developer simply changes the text constant. But maybe it shouldn’t have been changed all the places the text constant is used. But maybe the code should had been re-designed instead, but that is a different story.
3) Well, here I have to agree about preferring the usage of TESTFIELD and FIELDERROR and other standard NAV error messages. I just hate seeing code like this: IF NOT FIND(‘-‘) THEN ERROR(‘xxx not found.’) A simply FIND(‘-‘) gives an error message the is a lot better (and multilanguage enabled :-))
So in short I just don’t get the fuzz about enforcing the usage of text constants in every single modification in every single simple customization. However; I do prefer the usage of NAV error messages compared to homemade messages, unless they actually add additional information to the user.
Peter:
Thanks for comments. I agree with most of what you said, but I must reaffirm my position. So:
1) Yes, you are right, about 95% of the code is probably used solely in the country where it was developed, however it is not only about code being used outside the original country. There are situations where even if the code is used only in original countries, you still have people not speaking that language fluently, still working in the system. I figure in today’s global market, this is the case more often than not. I also agree that when expanding to another countries changing hardcoded constants into text-constants is the least of problems, but it still is a problem, which could be easily avoided. If you have a project full of such constants, even if it is the least of problems, it is still going to consume a lot of extra, and usually unplanned time during localization, which is going to put extra and unnecessary pressure on time and budget, or on development team and deadline. I had a chance to work on such a project, and believe me, it wasn’t any fun at all. And it could have been avoided so easily in the first place. Careful planning and design is much better than hiding behind statements such as: “Who is going to need it anyway.” If for nothing else, IMHO, texts shouldn’t be hardcoded for the sake of best practice alone.
2) You are completely right at this one. It can easily go another way around, and text constants themselves aren’t going to mitigate this issue. My point was more in direction of how people adhere to copy/paste solutions, thus usually generating unnecessary duplicates, rather than intended ones, but I didn’t put it well, so your comment is totally in place.
3) You agree with me, so I agree with you 🙂
In general, my humble, but strong opinion is that best practices are called best for reason, and that any mechanism which can help you save time in future, regardless of how little that time might be, should be leveraged.
Dave:
Come on, don’t take those attributes too seriously. Hardcoding is ugly, not necessarily people who hardcode. I’ve seen some pretty good looking developers hardcode 🙂
And you are right, I didn’t ever mention TextConstants by their given name. Sorry for that. I take too much for granted, but I hope that most of people understood that it was about them, at least you two who commented on the post did, so thant you for pointing it out.