Module structure

1C: Enterprise 8.2 /
For developers /
Code Conventions

Table of contents

1.1. In the program module (general modules, modules of objects, modules of object managers, modules of forms, commands, etc.) in the general case the following sections may be present in the following sequences :

Some sections may be present only in modules of a certain type. For example, event handlers for form elements can be present only in form modules, and the variable description section and initialization section cannot be defined in non-global general modules, object manager modules, record sets, constant values and session module.

The requirement to divide the module code into sections is intended to increase the readability of the code and simplify the introduction of changes to the code by different authors ( by developers ) as in the collective development, and in the refinement of application solutions for specific implementations.

1.2. Template (blank for copying) sections for common modules:

////////////////////////////////////////////////// ////////////////////////////// // // // //////////// ////////////////////////////////////////////////// ////////////// //////////////////////////////////// //////////////////////////////////////////// // // SOFTWARE INTERFACE // ////////////////////////////////////////////////// //////////////////////////// // SERVICE PROCEDURES AND FUNCTIONS

Section "Program interface" contains export procedures and functions intended for use by other configuration objects or other programs (for example, through an external connection).
The section "Utility Procedures and Functions" contains the procedures and functions that make up the internal implementation of a common module. In cases where the common module is part of some functional subsystems that include several metadata objects, this section can also contain service export procedures and functions intended only to be called from other objects of this subsystem.
For bulk common modules, it is recommended to divide this section into subsections, according to the functional attribute. Subsections are preceded by a commentary, which is recommended to issue in a similar way. For example:

////////////////////////////////////////////////// ////////////////////////////// // Information base update

1.3. Template for the design of sections for object modules, managers, record sets, treatments, reports, etc .:

////////////////////////////////////////////////// ////////////////////////////// // SOFTWARE INTERFACE ////////////// // ////////////////////////////////////////////////// ////////////// // PROCESSORS OF EVENTS //////////////////////////////// //////////////////////////////////////////////// // // SERVICE PROCEDURES AND FUNCTIONS

Section "Program Interface" contains export procedures and functions intended for use in other configuration modules or other programs (for example, through an external connection). It is not necessary to place in this section export functions and procedures that are intended to be called solely from the modules of the object itself, its forms and commands. For example, the procedures for populating the table part of a document that are called from the fill processing in the object module and from the document form in the form command handler are not the program interface of the object module, since are called only in the module itself and from the forms of the same object. They should be placed in section "Utility procedures and functions."
The "Event Handlers" section contains event handlers for the object's module ( Prizavisi , PRO , etc.)
The section "Utility Procedures and Functions" has the same purpose as in the general modules.

1.4. Section design template for form modules:

////////////////////////////////////////////////// ////////////////////////////// // HANDLER OF EVENTS OF THE FORM ///////////// ////////////////////////////////////////////////// /////////////// // HANDLERS OF EVENTS OF ELEMENTS OF THE SHAPE OF THE FORM //////////////////////////// ////////////////////////////////////////////////// // // PROCESSORS OF EVENTS FORMS TABLES ////////////////////////////////////////// ////////////////////////////////////// // PROCESSORS OF TEAMS OF THE FORM /////// ////////////////////////////////////////////////// /////////////////////// // SERVICE PROCEDURES AND FUNCTIONS

The section “Form event handlers” contains the form event handler procedures: On Creating a Server , Opening , etc.
Section "Form element handlers" contains procedures for processing elements located in the main part of the form (everything that is not related to the tables on the form).
In the sections “Event handlers of the form table <form table name>” there are procedures for the handlers of the form table and table elements. For handler procedures, each table must have its own partition.
The section “Form command handlers” contains procedures for form command handlers (the names of which are specified in the Action property of form commands).
The section "Utility Procedures and Functions" has the same purpose as in the general modules.

See also: Rules for creating form modules

2. General requirements for sections of software modules.

2.1. The module header is a comment at the very beginning of the module. The module heading provides a brief description and application conditions.
For example:

////////////////////////////////////////////////// //////////////////////////// // // Client procedures and functions of general purpose: // - for working with lists in forms; // - to work with the log; // - for processing actions user in the process editing // multiline text , for example comments in documents; // - other. // //////////////////////////////////////////////// ////////////////////////////////

For form modules, it is recommended to place a description of form parameters in the header.

2.2. Variable description section . Variable names are assigned according to the general variable name rules , and their use is described in the article. Using global variables in software modules .

All module variables should be provided with a comment sufficient to understand their purpose. The commentary is recommended to be placed in the same line where the variable is declared.
Example:

Pem CurrencyAccounting Export; // Currency in which the accounting is kept Perem Address Supports Export; // Email address where error messages are sent

2.3. Software interface Export procedures and functions that make up its programming interface are placed immediately after the description of the variables. Such procedures and functions are intended for use by other configuration objects or other programs (for example, through an external connection), therefore they should be located in a “visible place” in the module.

See also: Description of procedures and functions.

2.4.1 Form event handlers, commands, and form elements . Before service procedures and functions in the form module, event handlers of the form are located, as well as event handlers for commands and form elements.

Methodical recommendation (useful advice)

It is recommended that handlers of one form element be placed together, adhering to the order of their following in the form editor's property panel. in the configurator .

2.4.2. Each event must have its own handler procedure. If the same actions should be performed when events occur in different elements of the form:

create a separate procedure (function) that performs the necessary actions
for each form element, create a separate handler with the default name
call the required procedure (function) from each handler.

For example, wrong:

& OnClient Procedure for ExecutingApplication (Element) Selection Parameters = New Compliance (); Options Selection. Paste ("By Author", By Author); Options Selection. Paste ("Executive", Executive); Set List Selection (List, Selection Options); EndProcedure & On Client Procedure for Authoring By Changing (Element) To Executive By Changing (Undefined); EndProcedure

right:

& OnClient Procedure to PerformIndicator (Item) SetSelection (); End Procedure & At Client Procedure By Author Changing (Element) Install Selection (); EndProcedures & OnServer Procedure SetSelection () Selection Parameters = New Compliance (); Options Selection. Paste ("By Author", By Author); Options Selection. Paste ("Executive", Executive); Set List Selection (List, Selection Options); EndProcedure

This requirement is due to the fact that the logic of the event handler procedures are not intended for use in the module code, but are called directly by the platform. Mixing these two scenarios in one procedure unnecessarily complicates its logic and reduces its robustness (instead of the one envisaged call scenario — upon an event from the platform — the procedure code must count on other direct calls from the code).

2.5. The event handlers for the object modules and the object manager are placed after the export, but before the utility procedures and module functions.

Methodical recommendation (useful advice)

It is recommended to place handlers, adhering to the order of their following in the description of the embedded language.

2.6. Utility procedures and module functions that are not event handlers, but constitute the internal implementation of a module, are placed in the module next to event handlers.

In cases where a common module is part of a functional subsystem that includes several metadata objects, this section can also contain service export procedures and functions intended only to be called from other objects of this subsystem.

Procedures and functions related to each other by nature or logic of work are recommended to be placed together. It is not recommended to explicitly group the procedures and functions of the module into server, client, and functions without context, since such “technological” ordering complicates the understanding of the module's logic, diverting the developer’s attention to the details of its implementation.

2.7. The initialization section contains statements that initialize the variables of the module or object (form). For example:

Support Address = "[email protected]"; // Address to contact technical support Perform Initialization ();

Other materials on the topic:
update database , event handlers , software interface , handlers , procedures , template , headline , end of procedure , functions , interface , description , clipboard , copy , section , exchange , forms , an object , element , configuring , configurations , document

Materials from the section: 1C: Enterprise 8.2 / Developers / Agreements when writing code