The MorphX Development Environment and Tools

Compiler

Whenever you make a change to X++ code, you must recompile, just as you would in any other programming language. You start the recompile by pressing F7 in the X++ code editor. Your code also recompiles whenever you close the editor or save changes to an element.

The compiler also produces a list of the following information:

• Compiler errors These prevent code from compiling and should be fixed as soon as possible.

• Compiler warnings These typically indicate that something is wrong in the implementation. See Table 2-4, later in this section, for a list of example compiler warnings. Compiler warnings can and should be addressed. Check-in attempts with compiler warnings are rejected unless specifically allowed in the version control system settings.

  TABLE 2-4 Example compiler warnings.

  Warning message	Level
  Break statement found outside legal context	1
  The new method of a derived class does not call super()	1
  The new method of a derived class may not call super()	1
  Function never returns a value	1
  Not all paths return a value	1
  Assignment/comparison loses precision	1
  Unreachable code	2
  Empty compound statement	3
  Class names should start with an upper case letter	4
  Member names should start with a lower case letter	4

• Tasks (also known as to-dos) The compiler picks up single-line comments that start with TODO. These comments can be useful during development for adding reminders, but you should use them only in cases in which implementation can’t be completed. For example, you might use a to-do comment when you’re waiting for a check-in from another developer. Be careful when using to-do comments to postpone work, and never release code unless all to-dos are addressed. For a developer, there is nothing worse than debugging an issue and finding a to-do comment indicating that the issue was already known but overlooked.
• Best practice deviations The Best Practices tool carries out more complex validations. For more information, see the “Best Practices tool” section later in this chapter.

NOTE

Unlike other languages, X++ requires that you compile only code you’ve modified, because the intermediate language the compiler produces is persisted along with the X++ code and metadata. Of course, your changes can require other methods that consume your code to be changed and recompiled if, for example, you rename a method or modify its parameters. If the consumers are not recompiled, a run-time error is thrown when they are invoked. This means that you can execute your business application even when compile errors exist, as long as you don’t use the code that can’t compile. Always ensure that you compile the entire AOT when you consider your changes complete, and fix any compilation errors found. If you’re changing the class declaration somewhere in a class hierarchy, all classes deriving from the changed class should be recompiled, too. This can be achieved by using the Compile Forward option under Add-Ins in the context menu for the changed class node.

The Compiler Output window provides access to every issue found during compilation, as shown in Figure 2-15. The window presents one list of all relevant errors, warnings, best practice deviations, and tasks. Each type of message can be disabled or enabled by using the respective buttons. Each line in the list contains information about each issue that the compiler detects, a description of the issue, and its location.

FIGURE 2-15 The powerful combination of the X++ code editor and the Compiler Output window.

You can export the contents of the Compiler Output window. This capability is useful if you want to share the list of issues with team members. The exported file is an HTML file that can be viewed in Internet Explorer or reimported into the Compiler Output window in another AX 2012 session.

In the Compiler Output window, click Setup > Compiler to define the types of issues that the compiler should report. Compiler warnings are grouped into four levels, as shown by the examples in Table 2-4. Each level represents a certain level of severity, with 1 being the most critical and 4 being recommended to comply with best practices.