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 the next person in this code to not only be able to follow the logic of the code, but to understand the business reasons for it as well.
In case of a brand-new function, a simple statement of purpose is often all that is necessary. In case...
