In the standard application, all C/AL code is entered in English (United States). If all code is in the same language, it is easier to maintain the applications, including add-ons for several countries.

There must be exactly one space character on each side of binary operators such as assignment or plus, as shown in the following example:

y := (a + b) / 100;

There must not be any space between a unary operator and its argument, as shown in the following example:

y := -x;

In general, use an indentation of two character spaces, as shown in following the example:

IF a <> '' THEN
  Record.TESTFIELD(b);

When you split a C/AL statement into two or more lines, indent the continuation line by two characters, as shown in the following example:

MyVariable := 
  Variable1 + Variable2 * 2 + Variable3 * 3;

MyFunction(
  Expression1,Expression2,
  Expression3,Expression4);

Always start comments with // followed by one character space. Never use curly brackets ({ and }). To emphasize a comment, put it on a separate line and insert one empty line before it, as shown in the following example:

// Comment 
x := x * 2;

If the comment is on the same line as the C/AL code, add one character space before the comment sign, as shown in the following example:

x := '....'; // Comment

Error messages and other message strings must be entered as text constants. That way, the message can be easily translated and the users can see the same message in their own language.

Text constants will automatically be assigned unique IDs by C/SIDE. You can see the ID by opening the C/AL Globals window, selecting the text constant, and navigating to its Properties window.

When you are working in the C/AL Editor window, place the cursor on a text constant and the content of the text constant will be shown in the message line.

The IF and THEN statements should normally be on the same line. The ELSE statement should be on a separate line as shown in the following example:

IF x = y THEN
  x := x + 1 
ELSE 
  x := -x - 1;

If the last statement in the THEN part of an IF-THEN-ELSE statement string is an EXIT command or an ERROR command, do not continue with an ELSE statement, as shown in the following code snippet:

IF x <> y THEN 
  EXIT(TRUE);
x := x * 2;

When the BEGIN statement follows the THEN, ELSE, or DO statement, it should be on the same line, preceded by one character space as shown in the following snippet:

IF (x = y) AND (a = b) THEN BEGIN 
  x := a; 
  y := b; 
END;

REPEAT should always be alone on a line. Indentation of REPEAT statements is shown in the following example snippet:

REPEAT
  <Statement>;
UNTIL <expr>;

REPEAT
  <Statement>;
UNTIL <expr> AND
        <expr>;

When you use a CASE statement, indent the possibilities by two character spaces. Two or more possibilities on the same line are separated by commas (with no spaces), and the last possibility on a line is immediately followed by a colon (with no preceding space).

The action starts on the line after the possibility, further indented by two character spaces. If there is a BEGIN statement, it should be placed on a separate line unless it follows the ELSE statement. In this case, it should be on the same line as the ELSE statement.

CASE Field OF
  Field::A:
    BEGIN
      x := x + 1;
      y := -y - 1;
    END;
  Field::B:
    x := y;
  Field::C,Field::D:
    y := x; 
  ELSE BEGIN 
    y := x;
    a := b;
  END;
END;

If there are more than two alternatives, use a CASE statement; otherwise, use an IF statement.

Precise and consistent terminology helps the end user work with the application. Rules for naming and abbreviating everything will also help programmers gain an understanding of the base application and develop new features faster.

Remember that the user will see the value of the caption property but not the name property. But you, as a developer, must follow the naming convention in this section both for the name in English (United States) and for the caption in your local language.

Every Dynamics NAV object allows you to create functions inside itself. Instead of writing all your code in an existing trigger, break up your code into small steps. Write each small step's code in a separate function, give the function a name so that it explains what it does, and call your function from where you need it. This will ensure that you do not not write the same thing twice.

If the functions you are creating are to be called from one single object, create them on the object. If the functions are to be called from many objects, create them in a codeunit to group them all, or create them on a table if the function refers to a record of a table.