Module structure

Scope: managed applications, mobile applications, and ordinary applications.

1.1. Generally, application modules—common modules, object modules, object manager modules, form modules, command modules, and others—have the following structure:

  • Module title
  • Variable declaration
  • Export procedures and functions (API)
  • Event handlers
  • Internal procedures and functions
  • Initialization section

Some of the sections are valid only for certain types of modules. For example, the form item event handlers can be present only in form modules. Variable details and initialization sections cannot be defined in non-global common modules, object manager modules, record sets, constant values, and a session module.

We recommend that you divide the module code into sections to improve the code readability and simplify the code modification by different developers both in the case of team development and the application customization upon deployment projects.

1.2. We recommend that you divide large module sections into subsections in accordance with their functionality.

1.3. Sections and subsections are formatted as regions. Region names must comply with the requirements of the Naming variables standard.

1.4. Template of sections for common modules:

$$$

$$$
$$$
$$$

$$$
$$$
$$$

$$$
$$$
$$$

$$$

#Region Public
// Enter code here.
#EndRegion

#Region Internal
// Enter code here.
#EndRegion

#Region Private
// Enter code here.
#EndRegion
  • Public section contains export procedures and functions to be used by other configuration objects or other applications (for example, using external connection).
  • Internal section is intended for modules belonging to a certain functional subsystem. It must contain export procedures and functions that can be called only from other functional subsystems of the same library.
  • Private section contains procedures and functions that are a part of internal implementation of the common module. When the common module is a part of a functional subsystem, which includes several metadata objects, this section can also contain internal export procedures and functions intended to be called from other objects of the subsystem.

    For large common modules, we recommend that you divide this section into subsections according to the functionality. For example: 

$$$

$$$
$$$
$$$

$$$

#Region InfobaseUpdate
// Enter code here.
#EndRegion

1.5. Template of formatting sections for modules of objects, managers, record sets, data processors, reports, and other:

$$$

$$$
$$$
$$$

$$$
$$$
$$$

$$$
$$$
$$$

$$$
$$$
$$$

$$$

#Region Public
// Enter code here.
#EndRegion

#Region EventHandlers
// Enter code here.
#EndRegion

#Region Internal
// Enter code here.
#EndRegion

#Region Private
// Enter code here.
#EndRegion
  • Public section contains export procedures and functions intended to be used by other configuration modules or other applications (for example, via external connection). We do not recommended that you place export functions and procedures intended to be called exclusively from the object modules itself, its forms, and commands into this section. For example, document tabular section filling procedures, which are called from the filling data processor in the object module and from the document form in the form command handler, are not API interface of the object module as they are called only in the module itself and from the forms of the same object. Place them in the Private section.
  • Event handlers section contains the object module event handlers (OnWrite, OnPost, and other.)
  • Internal section has the same purpose as in common modules.
  • Private section has the same purpose as in common modules.

1.6. Template of formatting sections for form modules:

$$$

$$$
$$$
$$$

$$$
$$$
$$$

$$$
$$$
$$$

$$$
$$$
$$$

$$$
$$$
$$$

$$$

#Region FormEventHandlers
// Enter code here.
#EndRegion

#Region FormHeaderItemsEventHandlers
// Enter code here.
#EndRegion

#Region FormTableItemsEventHandlers
// Enter code here.
#EndRegion

#Region FormCommandsEventHandlers
// Enter code here.
#EndRegion

#Region Private
// Enter code here.
#EndRegion
  • Form event handlers section contains form event handlers: OnCreateAtServer, OnOpen, and other.
  • Form header items event handlers section contains the handlers of the items located in the main part of the form (everything not related to tables in the form).
  • "<Form table name> form table items event handlers" section contains handlers of form tables and table items. Create a separate section for handlers of each table.
  • Form command handlers section contains handlers of form commands. Their names are specified in the Action property of the form commands.
  • Private section has the same purpose as in common modules.

See also: Creating form modules

1.7. Template of formatting sections for command modules:

$$$

$$$
$$$
$$$

$$$
$$$
$$$

$$$

#Region EventHandlers
// Enter code here.
#EndRegion

#Region Private
// Enter code here.
#EndRegion

 

  • Event handlers section contains the CommandProcessing command handler.
  • Private section has the same purpose as in common modules.

1.8. The module cannot contain empty areas.

2. General requirements for module sections.

2.1. Module title is a comment at the beginning of a module. A module title contains its brief description and its application conditions.
For example:

////////////////////////////////////////////////////////////////////////////////
// Common client procedures and functions:
// - to manage lists on forms;
// - to keep event logs;
// - to process user actions upon editing
// a multiline text, for example, a comment in documents;
// - other.
//  
////////////////////////////////////////////////////////////////////////////////

We recommend that you place form parameter details in the title for form modules.

2.2. Variable details section. Variables are named in accordance with the general rules of naming variables. For more information on their use, see Using global variables in modules.

Provide all module variables with comments sufficient to understand their purpose. We recommend that you place the comment in the same line, in which the variable is declared.
Example:

$$$

$$$

$$$ 
$$$ 
$$$...

$$$

$$$

#Region Variables

Var PresentationCurrency;
Var SupportEmail;
...

#EndRegion

2.3. Public. Export procedures and functions constituting its API are located right after the variable details. Such procedures and functions are intended to be used by other configuration objects and applications (for example, via an external connection), therefore they must be placed in a visible location.

See also: Describing procedures and functions

2.4.1. Form, commands, and form items event handlers. Locate form event handlers and event handlers of commands and form items before internal procedures and functions in the form module.

Best practices

2.4.2. We recommend that you place handlers of one form item together according to their sequence in the form editor properties panel in Designer.

2.4.3. Assign a handler for each event. If different actions are required in case of events in different form items:

  • Create a separate procedure or a function that executes the required action.
  • Сreate a separate handler with a default name for each form item.
  • Call the required procedure or function from each handler.

Incorrect:

&AtClient
Procedure ByPerformerOnChange(Item)
 FilterParameters = New Map();
 FilterParameters.Insert("ByAuthor", ByAuthor);
 FilterParameters.Insert("ByPerformer", ByPerformer);
 SetListFilter(List, FilterParameters);
EndProcedure

&AtClient
Procedure ByAuthorOnChange(Item)
 ByPerformerOnChange(Undefined);
EndProcedure

Correct example:

&AtClient
Procedure ByPerformerOnChange(Item)
 SetFilter();
EndProcedure

&AtClient
Procedure ByAuthorOnChange(Item)
 SetFilter();
EndProcedure

&AtServer
Procedure SetFilter()
 FilterParameters = New Map();
 FilterParameters.Insert("ByAuthor", ByAuthor);
 FilterParameters.Insert("ByPerformer", ByPerformer);
 SetListFilter(List, FilterParameters);
EndProcedure

These requirements are provided as logically event handlers are not intended for use in the module code but are called directly by the platform. If you mix these two scenarios in a single procedure, its logic gets complicated and decreases its stability. Instead of one predefined call scenario by an event from the platform, the procedure code needs to consider other "direct" calls from the code.

2.5. Object modules and object manager event handlers are placed after the Internal section but before the Private section of the module.  

Best practices

2.5.1. We recommend that you place handlers according to their sequence in 1C:Enterprise language.

2.6. Internal procedures and functions of the module, which are not the event handlers but constitute the internal implementation of the module, are placed in the module after the event handlers.

When a common module is a part of a functional subsystem, which includes several metadata objects, this section can also contain internal export procedures and functions intended to be called from other objects of the subsystem.

We recommend that you place together procedures and functions associated by nature or logic. In the form modules, we do not recommend that you explicitly group the module procedures and functions into server functions, client functions, and functions without context as such ordering complicates understanding of the module logic and makes developers focus on its implementation details.

2.7. Initialization section contains operators that initialize variables of the module or object (form).
For example:

$$$

#Region Initialization

SupportAddress = "int@1c.com"; 
Init();
...

#EndRegion

 

#Region Initialize

SupportEmail = "int@1c.com";
Ctor();
...

#EndRegion

 

We recommend that you use the attached data processor to format code sections as regions.