Dynamics 365 Business Central: Preprocessor Directives in AL (Conditional Directives, Regions, Pragmas)

Dynamics 365 Business Central

Hello everyone.
This time I want to try Preprocessor Directives in AL. This feature applies to Business Central 2020 release wave 2 and later.

In AL, like in other programming languages, preprocessor directives can be used to make code conditional, to suppress warnings, or to enable expand and collapse in code. Preprocessor directives can be divided into the following groups. For more information about each type, use the links provided below.
・Conditional directives
・Regions
・Pragmas
Any code can be made conditional, including table fields, and checked using a conditional directive. To check code using a conditional directive, you must define a symbol to check. A symbol returns a boolean value; true or false. Symbols can be defined at the beginning of a source file and the scope of the specific symbol is the file that it is defined within. You can also define symbols in the app.json file, and then the scope is global for the extension.

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/directives/devenv-directives-in-al#conditional-directives

I will do a simple test one by one in this blog.

Conditional Directive (conditional compilation)

The following conditional preprocessor directives are supported in AL.

Conditional preprocessor directiveDescription
#ifSpecifies the beginning of a conditional clause. The #endif clause ends it. Compiles the code between the directives if the specified symbol being checked is defined.
#elseSpecifies a compound conditional clause. If none of the preceding clauses evaluates to true, the compiler will evaluate code between #else and #endif.
#elifCombines else and if. If #elif is true the compiler evaluates all code between #elif and the next conditional directive.
#endifSpecifies the end of a conditional clause that begins with #if.
#defineDefines a symbol that can be used to specify conditions for a compilation. For example, #define DEBUG. The scope of the symbol is the file that it was defined in.
#undefUndefines a symbol.
https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/directives/devenv-directives-in-al#conditional-directives

You can add “Conditional directives” anywhere in AL. Please note that the most important thing here is the preprocessor symbol.
For Example: ZYDebug

Symbols can be defined globally in the app.json file. 
For Example: “preprocessorSymbols”: [“ZYDebug”],

The code will run only when the “Symbol name” in “app.json” is consistent with the “Symbol name” in “Conditional directives”. In other cases, it does not run, this will be very helpful in debugging.

Region Directive (expand/collapse regions of code)

The #region directive is used to mark a block of code that you can expand or collapse. This can, for example, be useful for larger files for better readability or for focusing on code that you are currently working on. The #endregion specifies the end of a #region block of code.

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/directives/devenv-directive-region

#region block must be terminated with a #endregion directive.

#region block cannot overlap with an #if block. However, a #region block can be nested in an #if block, and an #if block can be nested in a #region block.

Then you can expand or collapse the codes in the regions.

This feature can improve the Readability of Your Code.

Pragma Directive (disable/enable warnings and implicitwith)

The #pragma directive gives the compiler special instructions for the compilation of the file in which it appears. The #pragma directive has a number of actions that can be used with the pragma instructions below, these are disablerestore, and enable.

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/directives/devenv-directive-pragma

Now AL supports the following pragma instructions (2020/10/05):
Pragma ImplicitWith

The #pragma implicitwith instruction changes the compiler behavior to not create an implicit with. This can be used as a temporary solution to avoid getting warnings on the usage of implicit with statements in the code, that you plan on rewriting but just have not fixed yet. With the #pragma implicitwith disable you disable the emit of implicit with warnings for a specific location in code that follows the instruction, and with #pragma implicitwith restore you restore the warning back to it’s original state. If you do not restore, the disable instruction is valid for the rest of the file.

Pragma Warning

The #pragma warning instruction can enable or disable certain warnings. This can be used as a solution to avoid getting warnings on, for example, string length on fields that you cannot change. With the #pragma warning disable statement you disable the emit of the warning for a specific location in code, and with #pragma warning restore you restore the warning back to it’s original state. If you do not restore, the disable instruction is valid for the rest of the file.

#pragma implicitwith is just to deal with the warning of “with” function, let’s test #pragma warning.

For example, there are 100 warnings in the following object “NewCustomerList.Page.al”.

You can enter “#pragma warning disable” to ignore all warning.

Or, enter “#pragma warning disable AL0604” to ignore “AL0604” warning.

These Preprocessor Directives have long existed in other languages, such as C#, and this time I am so happy that it has been added to AL.

Update 2023.04.12: Business Central 2023 wave 1 (BC22): New rule to enforce pragma warning ‘disable’ specifying a disabled rule (CodeCop Warning AA0246)

Hope this will help.
Thanks.

コメント

Copied title and URL