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 ...

Get Programming Microsoft Dynamics NAV - Fifth Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.