When we are creating or modifying software, we should always document what we have done. It is often difficult for developers to spend much time (time equals money) on documentation because many don't enjoy doing it, and the benefits to customers are difficult to quantify in advance. A reasonable goal is to provide enough documentation so that a knowledgeable person can later understand what we have done, as well as the reasons why.
If we choose good variable names, the AL code will tend to be self-documenting. If we lay our code out neatly, use indentation consistently, and localize logical elements in functions, then the flow of our code should be easy to read. We should also include comments that describe the functional reason for the change. This will help the next person working in this code not only be able to follow the logic of the code, but to understand the business reasons for that code.
In the case of a brand-new function, a simple statement of...
