Skip to Content

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, non-global common modules and session modules, as well as manager modules for objects, record sets, and constants cannot contain the variable declaration section. And only form modules can contain event handlers for form items.

Stick to this structure to improve the code readability and make the modules easier to maintain.

1.2. We recommend that you split up large sections into subsections by their functionality.

1.3. Specify each section or subsection as a region. Region names must comply with the requirements specified in Naming variables.

1.4. The structure template for a common module:

#Region Public

// Enter code here.

#EndRegion

#Region Internal

// Enter code here.

#EndRegion

#Region Private

// Enter code here.

#EndRegion

  • The Public section contains export procedures and functions, which can be called by other configuration objects or other applications.
  • The Internal section contains non-export procedures and functions, which can be called only by subsystems of the library.
  • The Private section contains procedures and functions that are called only inside the module. If a common module belongs to a subsystem that contains several metadata objects, this section can also contain internal export procedures and functions to be called from these objects.

    We recommend that you split up large Private sections into subsections by their functionality. Example:

#Region InfobaseUpdate

// Enter code here.

#EndRegion

1.5. The structure template for an object module, manager module, record set module, data processor module, and others:

#Region Variables

#EndRegion

#Region Public

// Enter code here.

#EndRegion

#Region EventHandlers

// Enter code here.

#EndRegion

#Region Internal

// Enter code here.

#EndRegion

#Region Private

// Enter code here.

#EndRegion

#Region Initialize

#EndRegion

  • The Public section contains export procedures and functions, which can be called by other configuration objects or other applications. It is not recommended that you place into this section export functions and procedures that will be called only from the object's modules, forms, and commands. For example, procedures that fill in tabular sections and are called from the filling data processor in an object module and from document form in a form command data processor are not part of the module's API. Place such procedures and functions into the Private section.
  • The Event handlers section contains object module event handlers, such as OnWrite and OnPost.
  • The Internal section contains non-export procedures and functions, which can be called only by subsystems of the library.
  • The Private section contains procedures and functions that are called only inside the module.

1.6. The structure template for a form module:

#Region Variables

#EndRegion

#Region FormEventHandlers

// Enter code here.

#EndRegion

#Region FormHeaderItemsEventHandlers

// Enter code here.

#EndRegion

#Region FormTableItemsEventHandlers<FormTableName>

// Enter code here.

#EndRegion

#Region FormCommandsEventHandlers

// Enter code here.

#EndRegion

#Region Private

// Enter code here.

#EndRegion

  • The Form event handlers section contains form event handlers, such as OnCreateAtServer and OnOpen.
  • The Form header items event handlers section contains the handlers of the form items, except for the table items.
  • The Form table items event handlers <form table name> section contains handlers of the tables and table items. For each table, create a section with event handlers.
  • The Form command event handlers section contains the form command handlers whose names are specified in the command's Action property.
  • The Private section contains procedures and functions that are called only inside the module.

See also: Creating form modules

1.7. The structure template for a command module:

#Region EventHandlers

// Enter code here.

#EndRegion

#Region Private

// Enter code here.

#EndRegion

  • The Event handlers section contains the CommandProcessing command handler.
  • The Private section contains procedures and functions that are called only inside the module.

1.8. Modules cannot contain empty regions.

2. General requirements for module sections.

2.1. The comment at the top of a module is the module title. A module title contains a brief description and application.
Example:

////////////////////////////////////////////////////////////////////////////////

// Common client procedures and functions:

// - to manage lists in forms;

// - to manage event logs;

// - to process user's actions when they edit

// multiline text, such as document comments;

// - other.

//

////////////////////////////////////////////////////////////////////////////////

For form modules, in the title, describe the form parameters.

2.2. Variable declaration section. Variable names must comply with the variable naming requirements. For more information on how to use variables, see Global variables.

Provide each variable with a comment that describes its purpose. It is recommended that you place the comment in the line where you declare the variable.
Example:

#Region Variables

Var PresentationCurrency;

Var SupportEmail;

...

#EndRegion

2.3. The Public section. After variables, declare export procedures and functions. Export procedures and functions are called by other objects and applications, that's why they must be grouped into a section.

See also: Describing procedures and functions

2.4.1. Form, command, and item event handlers. Place event handlers after the Public section.

Best practices

2.4.2. It is recommended that you place the handlers of one item next to each other and in the same sequence as they appear on the property panel in Designer.

2.4.3. Each event must have its own event handler. If different events result in the same action, do the following:

  • Create a procedure or a function that executes the action.
  • For each item, create a handler with the default name.
  • Call the procedure or function from the handlers.

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:

&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

This requirement is based on the platform feature: event handlers are not supposed to be called by the module. Instead, they are called by the platform. If you combine both approaches in one procedure or function, it will impact its consistency and robustness.

2.5. Place Object module and object manager module event handlers after the Public section and before the Private section.

Best practices

2.5.1. It is recommended that you place event handlers in the same sequence they are supposed to be executed.

2.6. Place the Internal procedures and functions that provide the internal implementation of the module, that is, don't handle events, after the event handlers.

If a common module belongs to a subsystem that contains several metadata objects, this section can also contain internal export procedures and functions to be called from these objects.

Place related procedures and functions next to each other. In form modules, it is not recommended that you group the procedures and functions by the context or client-server implementation. Such technology-driven ordering makes the module logic more complicated and might confuse the reader.

2.7. The Initialize section contains operators that initialize module's variables or a form.
Example:

#Region Initialize

SupportEmail = "support@1c.com";

Ctor();

...

#EndRegion

#EndRegion

   

Icon/Social/001 Icon/Social/006 Icon/Social/005 Icon/Social/004 Icon/Social/002