The first thing that many people think of when discussing Natural Language Programming is the very scientific concept of talking to a computer in a natural language and having the code generated automatically. These concepts are important for search engines and artificial intelligence (AI).
However, Natural Language Programming can also help us in writing code that is easier to read, understand, maintain, and even debug. Although it sounds very modern, a lot of traditional programming languages, such as Cobol and SQL use Natural Language to make the code easier to read. Take the following example:
select [No_], [Name] from [Contact] where [Name] like '%Mark%'
The C/AL programming language that we use in Microsoft Dynamics NAV is based on Pascal, and is traditionally not considered readable as a natural language. If we want to apply readability to C/AL, we have to implement a concept that we will refer to as multilevel code.
Note
This video explains Natural Language Programming for C/AL. You can watch it at https://www.youtube.com/watch?v=18b710d6nMg.
With multilevel code, we will split the technical code, which we will refer to as "nerdy code" from readable functions.
Let's look at an example, releasing a Sales Order, Codeunit 414:
This Codeunit does a lot of things that are hard to understand by just reading the code, and intuitively most developers will start adding comments to explain what they are doing and in which step; both for themselves to understand, and for others after them to be able to maintain the code.
However, adding these comments does not make the code easier to read. It adds lines to the function, spreading logic across multiple pages. In this example, the commenting code is an anti-pattern.
Let's see how we can implement a complex function using Natural Language Programming, and how this makes the code more readable and easier to maintain.
We will implement a relatively straightforward programming task. Create a script to make an invoice for customer number 10000 (The Cannon Group PLC), and item number 70000 (Side Panel).
Before jumping into the code, we can write down the required steps for this function, which are as follows:
- First, create a New Document.
- Then, test if the Customer is not blocked.
- Read Customer 10000.
- Next, save the Document to the Database.
- Create a Sales Line.
- Test if the Item is not blocked.
- Then, select the Item 70000.
- Save Line to Database.
- Finally, open the Invoice Page.
To implement this, instead of directly writing code we will create a function for each step, such as the following screenshot:
This makes very clear what we want to achieve, and it is easy to read even for non-technical people.
The functions contain the "nerdy code", which is harder to read:
This code can be as simple as MODIFY if we look at the SaveHeaderToDatabase function, which means to save the header to the database, which is more readable than the programming term.
There are a couple of things to realize when starting to implement this methodology.
When we want to change what a function does, we have to check if the name still makes sense. The name of the function explains what we want to do.
If our function requires us to loop through a dataset and perform a function on each of the rows in the dataset, we cannot put all the readable functions in one place if some of the functions have to be inside the REPEAT UNTIL loop, which is inside the function.
Since Microsoft Dynamics NAV 2013 a function name, it can contain up to 132 characters, allowing us to write functions as follows:
ForEachSalesLineCreateShipmentLineAndItemLedgerEntry.
This way, the reader understands that the function contains more than one step, and uses the Go To Definition to further investigate. Of course, this function will also contain logical function names that make the code as readable as possible.
Implementing Natural Language Programming forces developers to think before they act and write code that does a better job of explaining itself.
This becomes very useful when debugging. Debugging in Microsoft Dynamics NAV is very often done by Functional Consultants or Power Users.
When they see a code that is structured in a more readable way, it will be easier for them to understand the intention of the developer.
