We did it (again)!

On behalf of the Dynamics AX 2009 development team I'm proud to announce that as of build 5.0.529.0 we have reached zero X++ best practice errors in the SYS layer.

Version 4.0 was the first release of Dynamics AX without any best practice errors. Reaching this level of code quality was a mammoth effort; due to the huge backlog and many new TwC related BP rules.

In Dynamics AX 2009 the goal was significantly easier to reach, as we didn't have any backlog. However; we have introduced more than 60 new BP rules, including validation of XML documentation, inventory dimensions, upgrade scripts, workflow, list pages, AIF and performance. On top of this the SYS layer now contains much more functionality than ever before - the AOD file alone has grown with more than 50%. All of this now conform to the Best Practice rules implemented.

What does this mean for you as an X++ partner developer?

  • When you use the best practice tool, and it reports a BP error - then you should pay attention to it, as you introduced a problem.

  • The high quality of the code in the SYS layer should overall make your life easier, as it conforms to a set of standards, making the code easier to understand across the entire application.

For more information on MorphX Best Practices see: Channel 9 Screencast, or MSDN.

For more information on the importance of static code analysis see: Compiler warnings - and so what?

Comments (5)

  1. Adam:

    If you have access to the latest build of AX 2009, take a look in the class: SysBPCheckAIFDataObject to see what BP rules for AIF has been implemented.

    As far as I can see the rules primarily ensures consistency between data objects, queries and generated classes.

    Please log a request through Connect on the performance issues you are seeing.

  2. Adam says:

    Can you speak to the AIF performance updates that you mention?  We are currently running AIF on some of the latest builds of AX 4.1 and have noticed that it is very slow.  Has this been addressed?

  3. Ricard:

    Very few BP rules support being suppressed by adding this comment. The rules supporting suppressions are rules that have valid exceptions, where in most cases the fix is to manually review the code and ensure it is not subject a particular type of issue. After the review we flag the issue by adding this comment, so it won’t show up again. Or in other words: The rule was not acurate enough and thus yields false best practice errors. I believe that about 10 BP rules can be suppressed out of more than 300.

    In 5.0 you will also find this comment – which is where it should be. It is not a sign of poor quality. On the contrary.


    Development best practices are far more outreaching than a tool can ever be. E.g. it is a best practice to use good variable names – but it is hard to implement a rule validating that a variable name is good.

    If your glass was half empty in 4.0, I guess, we just poured 60 new BP rules into it.

  4. dewetha says:

    I find it interesting that the screen casts’ opening minutes state that the BP tool catches less than 50 pct of the best practices defined in the SDK.

    I would be more thrilled to hear that 100 pct of the sys layer followed all best practices. Of course I realize that is a huge effort but it is certainly more worthy of a round of applause than saying you can compile your source code to an inferior best practice tool.

    I guess I am in a “the glass is half empty" mood  today. I don’t mean to rain on your parade.

  5. Richard says:

    Does this mean you fixed the code or just finished adding "//BP Deviation Documented" everywhere like the 4.0 code?

Skip to main content