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.