Code compiling

One of the most common overlooked areas of the DAX system is the compile. A clean compile will go a long way to making you system stable, which is critical part of the requirement for an ERP system.

There are two compile stages: X++ and CIL. The X++ compile consists of four element: Errors, Warning, Best Practices and TODOs.

You have to ensure your environment has zero Errors to be able to complete the CIL compile, but the other items do not prevent you from moving, forward, but often should be reviewed and rectified to give you zero errors, zero warning, zero best practice deviations and zero TODOs.

Warnings, for the most part are often caused from lazy coding, with messages like Assignment/Comparison loses precision. This message is caused by passing a variable were the receiving variable holder is not of the same type, often real numbers to integers, and should have been converted prior to passing. Clearing these warnings is often a straight forward process and should be were possible resolved.

Best practices’ are a little more subjective, many of them should be resolved, they are best practices for a reason, and while take a little effort, do give you a more complete solution. There are however some best practices that can and often should be ignored. But these should be reviewed and determined by the technical team looking after the system, and can be disabled if truly note required. This will allow you to focus on the best practices that should be followed and resolved before the code is released.

TODOs are a useful item for developers. It allows notes to be added to code as a reminder that code is not complete and needs to be reviewed. This is a pet peeve of mine, as I often find when I look at system, many TODO with notes like ‘need to complete’ or ‘need to test this’, but these TODOs are located in the production system. So does this mean the code is not complete? It is hard to tell when you were not the developer of the code being reviewed, but it does raise some concern. I feel developers should review and clean out these TODOs before the code is released so we ensure the system is complete and clean.

At the end of the day, the quality of the code does play an important part in making your system stable. Rushing code and code releases is a risk to your environment and data, and the cost to clean up a bad code release into a production environment can be very high, while getting the code right and clean is a lot cheaper is done right the first time.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s