Guidelines for Placing C/AL Code

The following are simple guidelines for placing C/AL code:

In general, place the code as close as possible to the object on which it will operate. This implies that code which modifies records in the database should normally be placed in the triggers of the table fields that are involved.

In reports, always maintain a clear distinction between logical and visual processing and position your C/AL code accordingly. This implies that it is acceptable to have C/AL code in a section trigger if that code controls either the visual appearance of the controls or whether the section should be printed. Never place code that manipulates data in section triggers.

The principle of placing code near the object on which it operates can be overruled in some situations. One reason to overrule this principle is security. Normal users do not have direct access to tables that contain sensitive data, such as the General Ledger Entry table. If you place the code that operates on the general ledger in a codeunit, give the codeunit access to the table, and give the user permission to execute the codeunit, you will not compromise the security of the table and the user will be able to access the table.

There are reasons other than security for putting a posting function in a codeunit. A function that is placed in a codeunit can be called from many places in the application, including, perhaps, some that you did not anticipate when you first designed the application.

Reusing Code

The most important reason for placing C/AL code consistently, and as close to the objects that it manipulates, is that it lets you reuse code. Reusing code makes developing applications both faster and easier. More importantly, if you place your C/AL code as suggested, your applications will be less prone to errors. By centralizing the code, you will not inadvertently create inconsistencies by performing essentially the same calculation in many places