2015 m. birželio 17 d., trečiadienis

AX Source Code Quality: Top 10 X++ Coding Commandments 1.1

Hello AX Word,

This time I came up with an idea to list top 10 coding guidelines. We would all write a better code if we followed them.

      0. You shall check your code for best practices.
  1. You shall use a proper case for X++ code: start variables, functions, keywords with a lower letter; start application elements with a capital letter.
  2. You shall indent you code appropriately.
  3. You shall add curly brackets around every if, else, loop, switch (except case) and while select statement.
  4. You shall use meaningful names of variables, functions and application elements.
  5. You shall add a single spaces around operators, after commas, if, switch, case, loop keywords.
  6. You shall not use spaces before function parentheses, case's semi-column, ++ and -- operator, after ! (exclamation mark).
  7. You shall avoid using hard-coded values, especially for interface texts.
  8. You shall breakdown long statements.
  9. You shall use column style alignment.
  10. You shall cleanup unused code.
The list is subject to change if I get a more valuable best practice than one above. So this was named 1.0 :)

P.S. I wonder if there is beautifier tool somewhere in the market?

Be aware and take care!

2015 m. birželio 8 d., pirmadienis

AX Source Code Quality: Complex Select Statement Layout

Hello AX World,

One of the key factors that make your code look ugly is layout. There is a very good guidance for that on MSDN site. Everything looks clear when you read it. But when it comes to coding you start wondering how should I make this select statement adhere to best practices? How should I align this complex where clause?

My basic rules are:

  1. Follow MSDN guidelines for select statement.
  2. Use proper indentation.
  3. Keep field list compact.
  4. Make where clause look nice.

Follow MSDN guidelines for select statement.

It also includes while select, update_recordset and delete_recordset.

There are some rules which I am not big fan of.
First is that boolean operators should be placed at the beginning of the line. Well, even standard code does not always adhere to that rule.

Does this look nice?
When I try to write boolean operators in the beginning of a line I often consider which style should I use A or B?


When I write boolean operators at the end it's almost no question.

Second is alignment of from/order by/group by/index keywords. I prefer indenting them twice for a better readability. But this can be questioned.

Use proper indentation

I follow these guidelines:
  • Indent once where and setting keywords;
  • Do not indent joins. Put them at the same level as first statement (see very last example);
  • Indent group by/order by/index and from (if its moved to a new line) at least once.
    I prefer indenting then twice.
Keep field list compact

Follow the rule: if a field list contains more than 5 fields or it exceeds 100 chars, break it down and use column alignment. Use one column then breaking down.
This rule applies for field list, order by, group by and setting field list.

Make where clause look nice

This one is not an easy task. Especially, then it is a very complex where clause with lots of ANDs an ORs.

Follow these rules:
  • One comparison per line except if it's very short.
  • Then using clauses indent expressions inside by one space except the first one. Keep the first expression in the same line as opening clause "(". Closing clause ")" should be placed at the end of the last expression inside the clause.
  • Rearrange expressions to make it more readable. Try to keep the similar expression close to each other. 
  • Then using NOT operator "!" treat is as part of expression. Don't use special alignment.
  • Then writing AND and OR at the end make them leveled as clauses so the structure can be easily recognized.
Consider this example. Does this look nice?
It's code from standard class BatchRun method serverProcessFinishedJobs

Does this look more readable?

Or maybe this?

You are more than welcome to share your experiences and best practices. Please give a proper reason why you are doing it one or another way.

Be aware and take care!