Elegant Code Part I - Intro and Naming Conventions

E = mc²

Elegant Code - Intro

Naming Conventions, Boolean Logic, Boolean Logic Formatting, Indentions, Comments, Commented Out Code, Local vs Global variables, Global variables vs Parameters, long running functions, Reports, Integration with External data. These are just a few topics that developers sift through in a normal day. I hope to touch on these and more in this series of blogs.

First, let’s compare NAV standards with Einstein:
Energy := Mass * POWER(SpeedOfLight,2)
vs
E = mc²

Obviously, E = mc² is much more elegant. It’s also an equation that helps describe one of mankind’s most intriguing theories: The Theory of Relativity. In NAV, it’s doubtful that you would ever encounter a problem that requires as complex of a solution. I would say that elegance in E = mc² is in its simplicity and brevity. This simplicity obviously would not fly in NAV, for instance, when applying a value to an Item Ledger Entry, i.e., ile.qr := v * i. However, I would also say that NAV is very complex and voluminous, the type of complexity that you can’t simplify in code.

“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.” Antoine de Saint-Exupery

Elegance is something I try to attain in all development projects. What is elegance? Code Readability, Adhering to Established Standards(within NAV and within the project), Performance, Properly pairing the size and complexity of the Technical Application to the size and complexity of the problem, Extensibility and Maintainability.

Rarely can a project afford the most elegant solution possible for a given problem. Maintenance and customizations to base NAV often don’t require much but to modify existing functionality. We will adhere to the elegance in the architecture that already exists. We don’t want to refactor existing base code just to make it more elegant. In fact, an opportunity exists for elegance in customizations that add value yet have minimal impact on base NAV code.

As an upgrade team member at ArcherPoint, I experience the good, bad and not-so-elegant. In upgrades at least, elegance usually flys under the radar trouble free. We have automatic code merging tools that compare the old code with the new code and will determine differences in the client’s customized code and merge it into a new customized upgraded object. If the code is merged by the tool automatically, it has just passed one  criteria for elegance; Maintainability, if not, I have to manually merge the code. This is where I will likely see not-so-elegant code. When I merge code manually, I have to frequently refactor it to make it work properly with the new upgraded code. Not-so-elegant code can make this process troublesome to say the least.

Elegant Code - Part I - Naming Conventions

Writing code is easy. Writing easily readable code that a future developer can figure out, takes some thought. Sometimes, developers can over-think and over conventionalize when it's not necessary. They might put too much information in the code. For instance, a variable name of DataType Record might be redundantly prefixed with "REC". I say redundantly, because the datatype is available with a lookup into the Locals or Globals. There can also be too little information in the code, i.e., a variable name of DataType Report might be named "r".

“i” might be used as an integer variable name. I like this because “i” refers to a fundamental datatype, like “E” for energy, “m” for Mass and “c” for the speed of light in Einstein’s equation. By the way, speed of light is a universal constant, thus "c" is ultimately relevant.

Metatype Prefix is usually not-so-elegant - Name it what it is. If you are working with an Item record, do not prefix it with REC or _REC or r or anything else. Call it "Item". Make it easier for another developer to understand the code. Personally, meta-data in the form of prefixes to imply DataType is distracting and not helpful to me. If the variables are properly named, i.e., Item, or NextItemNo, I know what I’m dealing with: A Record and an Integer. However, I will still check the datatypes if I’m in doubt, regardless of what the previous developer named the variable.

While I generally don’t care for MetaDataType Prefixes, I do like and often use Scope Prefixes. For instance, if an Item variable is needed in Codeunit 80, in a custom function, I might call it locItem. This will prevent confusion when debugging. Codeunit 80 has a Global named Item. While NAV will compile with a local named Item, debugging would require second guessing or filtering on variable scope.

Underscore - In NAV, on any name, underscores should be avoided. Take a hint from Microsoft, there are no underscores in base NAV. Underscores not only make code harder to read in many ways, they also make it harder to search code. NAV doesn't quite yet have full intellisence as Visual Studio does. But, it always has had ways of looking up or scrolling through data. For instance, when zooming on a record, and looking for "Quantity on Hand", you simply type the letter q and the cursor goes to the first field that starts with q. Subsequent q's move the cursor to the next q field name. This functionality exists in the C/AL Symbol Menu and the debugger in the Variable window. Add an underscore to your variable name or field name and you lose that base NAV functionality and ultimately make it harder to understand the code.

Here is an example of a function with an underscore in the name. I can’t see the underscore in this function name, can you?

CamelCase is where you concatenate the names and capitalize the first letter of each word. This is good and prolific throughout base NAV.

Numbers should be avoided in Field and Function Names- But, are generally ok in variable names. For instance, GenJnlLine1, GenJnlLine2 is common in base NAV especially in posting Codeunits. In a field name, if a number exists as a prefix in a field, certain Excel integration tasks will fail miserably with little hint at why. I avoid numbers in field names. When you see them, it usually means non-normalized data.

When in doubt of anything in NAV, look at base NAV.

I hope this information will help you think more elegantly and ultimately make you a better developer.