Category Archives: Clean Coding Principles

This determines the way you structure your code and objects. The patterns help you organize your application and enhance upgradability and maintainability across developers and partners. Many of the patterns are derived from Object Oriented Programming. Examples are Hooks, Façade, Encapsulation and Natural Language Programming.

NAV2016CU2 | Obsolete Commands Cleaned Up!

When CU2 was released, I totaly forgot to test something I should have.

Based on my “what the BEEP” post my friends at Microsoft decided that it was time to “clean up” and gave me a heads up.

If you type “BE” in NAV2016CU2 the keyword you get is BEGIN, not BEEP.


NAV2016CU2 Intellisense

From what I have been told the obsolete commands are hardcoded. If you find anything that should be removed, just reply to this blog. Microsoft folks read it :). (Trust me I know).

As far as I could test I could not find the BEEP in the Symbol menu either, but I might have looked in the wrong place.

NAV2016 | Hooks vs. Events

One question that is raised a lot lately is how events and hooks are compared and when to use events and when to use hooks.

The answer to this question is very simple if you are not on NAV2016, as one of my Partner Ready Software friends said at NAVTechDays: you can only use hooks.
Continue reading

Implementation Pattern #3 | Encapsulation

Not a big reader? Watch the video of this blog here on YouTube!

Encapsulation is one of the four corner stones of object oriented programming and it is about componentizing your software, it’s basics go back even to the 1970ies. In this article we will investigate how we can introduce this concept in Dynamics NAV.

Elements of encapsulation

Encapsulation is about creating small reusable components grouping features that belong together.


A very important rule here is to be as local as possible. The intention of being local is to prevent the wrongly use of features.

Within Encapsulation a programming language typically allows override, just in case it is required and the programmers know what they are doing and why.

Encapsulation is tightly related to the Object-Method-Property model that we discussed in the first video of this series of implementation patterns.


If we take some keywords from this list, we need to define Small, Usable, Local, Hide and Override.

Microsoft Dynamics NAV.

A small reusable element can be a Codeunit. Within the Codeunit we can have functions that can be global and local. Global functions can be accessed always when we declare the Codeunit as a variable. Local functions can only be accessed from the object itself, thus the Codeunit. This allows us to be as local as possible and implement encapsulation.

In Microsoft Dynamics NAV2015 functions are local by default. This is to encourage encapsulation.


Let’s take an example. We could create a Codeunit for VAT and SalesTax calculation. This Codeunit has one global function that is called CalculateVATAndTAX which takes an argument table as a parameter. The business logic will be in local functions that are only accessible from within the Codeunit.

With this example we have creates a small but usable component of features that belong together and business logic that is as local as possible. Hence we have implemented encapsulation in Microsoft Dynamics NAV.

In the Application

Unfortunately I have to admit that encapsulation is not implemented throughout the product. There are reasons for that which I will explain in another episode of the series. But it exist. A very good example is Inventory Profile Offsetting. This Codeunit has a global function that takes an Item, some setup and other parameters and then start a logical order of functions. These functions are local.


The goal of using local functions is to avoid the wrongly use of them. This way the designer makes a clear intention of which functions you can call, and which functions should never be called from outside the object. This is one of the fundamental basics of encapsulation.

Mapped to C#

If we take this learning and go back to the first pattern of this series, Class, Method, Property we can now expand this with Public and Private, these are the keywords for Global and Local functions in C#.


Natural Language Programming

We can also relate this to the second pattern, natural language programming where we separate readable code from nerdy code. The readable code are the local functions and the nerdy code is the C/AL code in these functions.


We are starting to get a completer picture here, and this is why I’ve put these articles in this specific order.


Now we discussed Small, Usable, Local and Hide. We have not discussed Override. There is a good reason for that.

Most programming languages have built in mechanisms for overriding. C++ uses friend and C# and other languages have reflection.

C/AL does not have anything built in that allows this. If we want to override, we have to hack into the source code and change the behavior. This is the reason NAV is open source.


However there is another implementation pattern that allows override, which is the façade pattern. This pattern is based on decoupling and should be implemented if there is a clear expectation of overriding being required. In Dynamics NAV it requires extra coding, objects and it makes the of the business logic intention less clear.

Global & Local

So does this mean that with encapsulation each Codeunit should have one global and multiple local functions? No. There are a number of patterns that require more than one global function in a Codeunit such as implementing API’s, management codeunits such as journal management and the Model View-View Model pattern. This often relates back to reusing global variables in memory state or keeping software features together in one class, which relates back to one of the fundamental basics of encapsulation.

Be as Local as possible

We can however create one clear statement: “Be as Local as Possible.”. Which is enforced by Dynamics NAV 2015.

So when we look at the key elements of encapsulation we can say that one of the corner stones of object oriented programming can be implemented in Microsoft Dynamics NAV and helps us to clearly structure our code and emphasizing the clear intention of the designer.

Implementation Pattern #2 | Natural Language Programming

If you want to read the first article about Implementation Patterns, here is the link.

If you prefer a video, it is on YouTube. The blog starts at 2:20 after a general introduction.

Natural Language Programming

I hear what you are thinking. A scientific concept like this, in C/AL. Yes, in C/AL.

Scientific Approach

If we look at Natural Language Programming as a concept there is first of all the scientific approach. Programming computers in natural English, or any other language, preferably via speech recognition. However, there is a lesser science fiction approach to the concept.

Multi Level Coding

This is multi level coding. Splitting the nerdy code, from the readable code.

Natural Language Programming has actually been implemented in some way in SQL and COBOL, it’s not new and we’ll try to apply it do Dynamics NAV.

If we look at SQL server syntax, you can see that readability is implemented in the language.


With Dynamics NAV we don’t have that, we have SETRANGE and SETFILTER and FIND. Also with SQL code get hard to read once you start adding business logic.

The approach we would like to you take when we talk about Natural Language Programming in Dynamics NAV, is to write two layers of code Readable Code and Nerdy Code. These layers should be separated.


Traditionally, if code is to nerdy and hard to understand the programmer will add comments. And if one programmer cannot understand the others code, the feedback will be, he forgot to put comments in the code!


This is untrue, comments are evil and should always be avoided.

Let’s look at an example.

The development task we will give our programmer is to create a script for a very popular customer who always buys the same item. A side board.

Instead of coding away, our developer starts thinking what steps need to be implemented.


So this is the code we end up writing.


Although this is very understandable code, it does nothing. We need an extra layer, the nerdy layer.


The nerdy layer contains the actual C/AL code that does the heavy lifting.

But wait! This is not all, there is a bonus. This makes debugging accessible for consultants and end users.

Even though general rules mostly say debugging is for developers, if all hens is on deck, everyone will start debugging.


And when Natural Language programming is implemented, this will have the same two layered approach and we can step over all the code that does not contain errors.

So where do you start with implementing this.

There are two approaches.

The first is to start writing the functions and then write the code. This is the preferred way.

The second option is to start with the classic approach and then break it down and create smaller pieces.

Remember that when loops are required, you need to create a very logical function name since you cannot see the functions inside the loop from the initial workflow. To support this pattern the function names can now be 132 characters.

There are two enhancements to the C/AL code editor that would improve using this pattern.

The first is to select a few lines of code and create a function from a right mouse click. (Thanks to Soren Klemmensen for the idea)


The second would be to see from the editor that a function has details or subfunctions.


As a reference video I would encourage watching How Do I Implement the C/AL Coding Guidelines which will be published in December 2014.

Remember, write readable code, and nerdy code and separate them. This will enhance readability of your code and improve maintainability.

Implementation Pattern #1 | Classes, Methods and Properies

So last week in this post I promissed you to publish the implementation patterns that help you structure your application to achieve repeatable and upgradable solutions that are easy to understand and maintain.

Not a big reader? You can watch the video of this blog post!

This is the first pattern and one of the most fundamental elements to understand before proceeding with the other patterns.

We will talk about ising classes, methods and properties in C/AL, a functional language.

Classes, Methods and Properties are elements of C#, an object oriented programming language. However there are certain elements that we can take from that language and map them to Dynamics NAV and make our daily lives easier.

This week I wrote two other posts in a series about Dynamics NAV and C# that discuss the same concept from another side. If you haven’t done so I recommend reading them first.

Dynamics NAV in C# | Part 2 | Classes (Updated)

Dynamics NAV in C# | Part 2 | Classes (Continued)

And here are the two other posts about C# and Dynamics NAV:

Dynamics NAV in C# | Part 1 | The Differences

Dynamics NAV is moving to C#, get ready to follow!

Let’s talk about the Pattern

The problem we are trying to solve with this pattern is the loose connection between tables in dynamics NAV and what you can do with it in other objects such as codeunits.

If we look at an example, we have the customer table, and a function in Codeunit 365 Format Address.


If we want to format an address in a report, as a developer I need to know that there is something like Codeunit 365, declare it as a variable and call the right function. There is nothing in Dynamics NAV that helps me find that function.

Another example, the sales header. With this I can call the post Codeunit or the Release Codeunit.


However, when I look at the sales order page, we see again that the codeunits are called as variables.

What would this look like in C#?

Let’s compare this to object oriented programming, C# and classes.


In C# the customer table would be a class and the fields would be properties that have a getter and a setter. The class has a method FormatAddress, and this calls out to a generic class.

Our Sales Header and Sales Invoice would also be classes. Probably in pure C# you would increase the object orientation with inheritance, but let’s leave this a simple example.


With a Sales Header I would be able to use the Method Post and with the Sales Invoice I could call the FormatAddress again.

Let’s do this in Dynamics NAV!

So what if we do this in Dynamics NAV.


We would create a function on the Customer Table called FormatAddress, and then on our report.


We don’t have to know the Codeunit anymore, but browsing through the Symbol Menu, the equivalent of Intellisense in the C/AL editor, I would see that a function FormatAddress exists and I just use it from my report.


The Table is the class, the Function is the Method and a Codeunit is a Class.

The same would work for the Sales Header.


This would have functions release and post. And on the page I can just call the functions.


This pattern has a number of advantages. First of all there is a clear intention of the programmer. Everything you can do with a record in the table is clearly specified on the object.


It reduces the learning curve for new developers, since by just looking at the functions in the symbol menu we can learn what we can do with the records in the table.

We can actually use the symbol menu. Using this pattern would make creating a Codeunit as a variable on pages and reports wrong. If you see a Codeunit on one of these objects, it is an indication that this pattern is not implemented.

When working on methods, developers have less chance of overlap changing the same object. This makes merging easier when the branches come together.

And it actually allows us to do versioning of business logic. This concept will be explained in another video or blog post.


There are some downsides too. If you create a Codeunit for each function, you get a lot of objects making managing the application less easy. Also having more than a hundred functions on a table does not exactly clarify the intention either.


Lastly if you call a table function from a page, the Go To Definition does not work which is highly annoying.


To avoid too many codeunits in your application, you might use the rule that if a function is less than 5 or 10 lines of code, you can write the code in the function. We’ll touch on that too when we will talk about natural language programming.