IF Without BEGIN and END Considered Harmful
In NAV, the IF statements can be written in one of two ways: either with BEGIN and END statements, or without. If you skip the BEGIN and END, your IF statement can only include a single instruction, and then it is assumed to be over.
So, this is legal:
IF (2 + 2 = 4) THEN BEGIN Foo := Foo + 1; END;
And so is this:
IF (2 + 2 = 4) THEN Foo := Foo + 1;
But I think the statement with the BEGIN and END is superior. I never write an IF statement without a BEGIN and END included, no matter what. Even if it’s something that shouldn’t need an additional set of statements, like an IF that immediately leads into a REPEAT, or an IF that immediately triggers an ERROR, I still always write my IFs with BEGIN and END.
There are a few reasons for this, and none of them include me having OCD. (At least, I hope none of them include me having OCD.)
Reason 1 is that I might need to insert an additional statement or two in the middle of the IF block for debugging purposes, and I can’t do an additional statement if there’s a limit of one statement to my IF clause. Believe it or don’t, the NAV debugger has some flaws, and sometimes it’s not the best tool for trying to resolve coding issues. Sometimes, I have to put MESSAGE boxes or temporary variables or something else into my code to try to track down an issue, and having an IF statement that’s already set up to accommodate me makes my life easier.
Reason 2 is that it makes the code easier to read. When there’s an IF statement without a BEGIN and END, it’s a lot tougher to figure out where that IF statement ends. This comes up when I run across the common IF [record].FINDSET THEN REPEAT . . . UNTIL [condition] construct that’s generally used to dig through a big batch of records. If there’s a lot of code in between the REPEAT and the UNTIL, it’s not readily apparently to me where the IF block ends after the UNTIL, and it can throw off my all-important code indention.
(As an aside, I heard a ghost story on an ArcherPoint camping trip about a NAV user who insisted on using three spaces instead of the standard two to indent code. I did not sleep well that night.)
Reason 3 is that it makes the code easier to maintain. Today’s IF statement may only need to do one thing, but I don’t just write code for today; I write it for use in production for the future, and months or years removed from when I wrote that code, I may need to alter the IF statement so that it does more than one thing, and so I might have to write a whole new IF statement to handle stuff with the BEGIN and END included this time. That doesn’t sound too bad, but it can lead to some problems when you’re comparing different versions of objects trying to reconcile differences during upgrades (or even when two developers have both changed the same object). The standard ArcherPoint coding practices call for production code to never be removed, only commented out and replaced with new code, and IF statements that don’t have BEGIN and END attached make this tougher.
And that’s my soapbox rant for today. Maybe there’s some sort of great performance-based reason for doing an IF without a BEGIN and END, or maybe there’s amazing argument for skipping them that has never occurred to me; if so, please leave it in the comments.