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.


  1. Robert Tuck says:

    This approach is excellent and would/will make the job of debugging code much quicker once adopted.
    Thanks and keep it coming.


  2. 1) Comments are not evil (but you use the statement to make other good points). Logical naming convension is a must and good abstration levels are key, we agree 100% on those! But still, the developer did have some thoughts when he/she wrote the code, maybe critical sections that might be need improvements or optimizations in the future, or, internal logic which is hard/impossible to quickly get from reading throuh code.
    Reading a block of code takes much, much, much longer than a well choosen comment line.

    2) You and I could find 1000 Things to add to the NAV Development Environment – because everything is missing. Question is, what can we do to make MS listen? MS Connect have failed in my opinion.

    Liked by 1 person

Leave a Comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.