In the earlier chapters, we discussed some documentation practices that are good to follow when making C/AL modifications. Here is a brief list of practices that should be followed:

• Identify every project with its own unique project tag
• Use the project tag in all documentation relating to the modification
• Include a brief but complete description of the functional purpose of the modification in a related Documentation trigger
• Include a description of the modifications to each object in the Documentation trigger of that object, including changes to properties, Global and Local variables, functions, and so on
• Add the project tag to the version code of all modified objects
• As much as possible, make all code self-documenting, using meaningful names for all data elements and functions, and breaking code segments into logical functions so that process flow is self-evident
• Bracket all C/AL code changes with inline comments so that they can be easily identified
• Retain all replaced code within comments using // or {}
• Identify all new table fields with the project tag