These Simple Coding Tricks Will Improve Your Productivity
It should be noted that I dislike modern web story headlines meant only to direct your attention to an article that provides little value. As such, please treat the headline to this article as a parody—albeit a parody based in truth, since this is an article that describes coding tricks. I should note that nothing in this article will help you lose weight, however. That was pure deception. I’m not apologizing, though; my son has been playing Lego Marvel Super Heroes. As such, I’m embracing shameless hucksterism in the spirit of the great Stan Lee, surely the greatest writer of the Marvel Age of Comics.
One of the issues that can come up in Microsoft Dynamics NAV (Navision) coding (and really in lots of other coding languages I’ve worked in, like C#) is that you’ll have a chunk of code that’s hundreds or even thousands of lines long that will not compile. And it won’t compile for a simple reason: You’ve made a syntax error, and somewhere you forgot to end a line with a semicolon, or you left out one of the ENDs in a block of nested IF and CASE statements.
When this happens, I spend a few minutes trying to find the right place for my missing bit of syntax, and if it’s not readily apparent, there’s a trick I use. I copy the whole function (or at least the huge block of code that’s giving me problems) into a text editor with line numbering enabled. (I generally use Notepad++ because it’s open source and free from extraneous stuff and it has tab support for when I have to juggle multiple text files, but you’re welcome to find another one.) Then I do a block comment to remove the whole chunk of code using my curly brackets (“{“ and “}”).
Once I’ve commented out enough stuff to get the object to compile, I head over to my text editor and find the halfway point of my code. I then uncomment the first half of my code and see if that compiles. That tells me if I need to look for my syntax error in the first half of the block or the second half. Once I’ve identified which half, I split it in half. And then I split that in half, until I’ve got things down to a small enough number of lines where I can look at it and say, “Oh, yeah, that’s where that semicolon goes.”
Sometimes, to get this to work, you have to identify specific IF statements and comment out just the code in those. And that can take a few minutes, but it’s still much easier than staring at a thousand lines of code until your eyes glaze over and playing “Where’s Waldo?” with semicolons. (Looking at you, OnRun trigger in codeunit 80.) This actually segues nicely into my next coding trick, specifically for dealing with big nested IF blocks.
Way back in the early 2000’s, when I was younger and less experienced than I am today, I interviewed with a company that wrote software for an unspecified industry. I was not hired there, and so I shall refrain from publically identifying them, as their stockholders would surely berate any members of management that were still around for passing on such a talented young coder such as myself, and their stock would immediately plummet. Part of the interview involved working with code samples, and they did an interesting thing where all of their IF statements (translated into C/AL, since they were a VB shop) looked like this:
Figure 1. IF statements from my interview with the unnamed company.
Now, I’m not sure that sure that every IF statement everywhere in code needs to do that, but there are times when you get into a bunch of nested IF statements, and the resulting code looks like this:
Figure 2. Nested IF statements.
By the time you’re done, you’ve got a whole bunch of IFs nested one inside the other, all within a REPEAT, and if you’ve actually got a bunch of code in those different IF segments, it can be easy to lose track of which IF you’re actually working in. When I get in a coding block like this, I like to think back to that interview and add comments to the END statements (and sometimes the END ELSE BEGINs as well), and the whole thing looks like this:
Figure 3. Nested IF statements with comments
You may accuse me of stealing that practice, but I prefer to think of it as reinterpreting it for a modern audience. (Also, I’m relatively certain that they themselves picked it up somewhere else. Reinterpreting things is generally considered acceptable, as Shakespeare himself only wrote two wholly original plays; all his other plays were histories or retellings of existing stories.)
Hopefully these are some helpful things you can try to keep yourself from spending hours banging your head against a desk. Now, I’ll close this blog entry in true Stan Lee fashion: Excelsior, true believers! ‘Nuff said!
If you have any further questions about this or other development issues, please contact one of our development experts at ArcherPoint. If you enjoyed this blog, read more of Tom Hunt’s blogs, or check out our collection of Development Blogs.