Best Practise checks in AX 2012

Best Practice	Example
Place the opening and closing braces each on their own line.	if (someExpression) { doSomething(); }
Do not omit braces. Braces are not optional because they increase code readability and maintainability. They should be included, even for single statement blocks.	if (someExpression) { doSomething(); }
Omit braces for switch statements. These braces can be omitted because the case and break statements clearly indicate the beginning and ending.	case 0: doSomething(); break;
Use a single space in the following cases: On either side of the assignment operator.	Correct: cust.Name = "Jo"; Incorrect: cust.Name="Jo";
After the comma between parameters.	Correct: public void doSomething(int _x, int _y) Incorrect: public void doSomething(int _x,int _y)
Between arguments.	Correct: myAddress(myStr, 0, 1) Incorrect: myAddress(myStr,0,1)
Before flow control statements.	Correct: while (x == y) Incorrect: while(x == y)
Before and after binary operators.	Correct: if (x == y) Incorrect: if (x==y)
After the semicolon between the parts of a for statement.	Correct: for (i = 0; i < 10; i++) Incorrect: for (i = 0;i < 10;i++)
Do not use any spaces in the following cases: After the opening or before the closing parenthesis.	Correct: myAddress(myStr, 0, 1) Incorrect: myAddress( myStr, 0, 1 )
Between a member name and opening parenthesis.	Correct: myAddress() Incorrect: myAddress ()
Before or after the brackets.	Correct: x = dataArray[index]; Incorrect: x = dataArray[ index ];
Before or after unary operators.	Correct: if (!y) Incorrect: if (! y)
Use four spaces as the standard indent. The tab key in code editor inserts four spaces. Indent in the following cases: The contents of code blocks.	if (someExpression) { doSomething(); }
Case blocks even though they do not use braces.	switch (someExpression) { case 0: doSomething(); break; … }
A wrapped line one indent from the previous line.	lastAccount = this.doSomething( cust, firstAccount, startDate, endDate);
Wrap lines that get too long to fit on a single line.
Wrap shorter lines to improve clarity.
Place each wrapped select and while select statement keyword at the beginning of a new line. The content associated with each keyword should be indented by one indent under the corresponding keyword.	select firstonly cust where someExpression1 && someExpression2 && someExpression3; select count(RecId) from cust where someExpression1 && someExpression2 && someExpression3; while select firstonly cust order by Name, AccountNum where someExpression1 && someExpression2 && someExpression3 { … }
Do not use more or less than four spaces to force special alignment.	Right lastAccount = this.doSomething( cust, firstAccount, startDate, endDate); Wrong (indent is 14 spaces) last = this.do( cust, firstAccount, startDate, endDate);
Put each indented parameter or argument on a separate line.
Use switch statements over consecutive if statements.
Do not use parenthesis around the value of the cases of a switch statement.
Do not put the closing parenthesis for a method call on a new line.

Best Practice	Example
Use Camel case naming for member variables, method names, and local variables.	serverClass;
Use Pascal case naming for Application Object Tree (AOT) elements.	AddressCountyRegion;
Prefix parameter names with an underscore (_).	myJob(Args _args)

Best Practice	Example
Do not use comments that repeat the code.
Do not use multi-line syntax /* … */ for comments. The single-line syntax // … is preferred even when a comment spans multiple lines.	public int getCount() { ; // This comment spans multiple // lines because it has // a lot to say. The use of // multi-line syntax is // not allowed. … }
Do not place comments at the end of a line unless the comment is very short. In most cases, comments should be placed above the code.	public class ArrayList { int count; // -1 indicates uninitialized array }

Labels and Text Guidance

The following list provides best practice guidance for labels and text.

• Use labels for text that will appear on the user interface.
• Put labels in double quotes.
• Do not concatenate multiple labels together.
• Use single quotes for text that will not appear in the user interface.

X++ Coding Standards [AX 2012]

• Declare variables as locally as possible.
• Have only one successful return point in the code (typically, the last statement), with the exception of switch cases, or when checking for start conditions.
• Keep the building blocks (methods) small and clear. A method should do a single, well-defined job. It should therefore be easy to name a method.
• Put braces around every block of statements, even if there is only one statement in the block.
• Put comments in your code, telling others what the code is supposed to do, and what the parameters are used for.
• Do not assign values to, or manipulate, actual parameters that are "supplied" by value. You should always be able to trust that the value of such a parameter is the one initially supplied. Treat such parameters as constants.
• Clean up your code; delete unused variables, methods and classes.
• Never let the user experience a runtime error. Take appropriate actions to either manage the situation programmatically or throw an error informing the user in the Infolog about the problem and what actions can be taken to fix the problem.
• Never make assignments to the "this" variable.
• Avoid dead code. (See Dead Code Examples.)
• Reuse code. Avoid using the same lines of code in numerous places. Consider moving them to a method instead.
• Never use infolog.add directly. Use the indirection methods: error, warning, info and checkFailed.
• Design your application to avoid deadlocks.