Microsoft Dynamics NAV

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 (or, money) on documentation because many don't enjoy doing it and the benefits are uncertain. A reasonable goal is to provide enough documentation so that a knowledgeable person following us can understand what we have done as well as the reasons why.

If we choose good variable names, the C/AL code will tend to be self-documenting. If we lay out our code 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 which describe the functional reason for the change. This will help ...