Internal documentation

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 (that is, 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.

When packaging your solution as an extension, you are not allowed to add documentation to standard Microsoft objects.

If we choose good variable names, the C/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...