Structure du module

1C: Enterprise 8.2 /
Pour les développeurs /
Conventions de code

Table des matières

1.1. Dans le module de programme (modules généraux, modules d’objets, modules de gestionnaires d’objets, modules de formulaires, commandes, etc.), dans le cas général, les sections suivantes peuvent figurer dans les sections suivantes: des séquences :

Certaines sections peuvent être présentes uniquement dans des modules d'un certain type. Par exemple, les gestionnaires d'événements pour les éléments de formulaire ne peuvent être présents que dans les modules de formulaire et la section de description de variable et la section d'initialisation ne peuvent pas être définies dans des modules généraux non globaux, des modules de gestionnaire d'objets, des ensembles d'enregistrements, des valeurs constantes et un module de session.

L’exigence de diviser le code du module en sections est destinée à améliorer la lisibilité du code et à simplifier l’introduction de modifications du code par différents auteurs ( par les développeurs ) comme dans le développement collectif et dans le raffinement de solutions applicatives pour des implémentations spécifiques.

1.2. Sections de modèle (vierges pour la copie) pour les modules communs:

• La section "Interface de programme" contient les procédures et fonctions d'exportation destinées à être utilisées par d'autres objets de configuration ou d'autres programmes (par exemple, via une connexion externe).
• La section "Procédures et fonctions de l'utilitaire" contient les procédures et les fonctions qui constituent l'implémentation interne d'un module commun. Dans les cas où le module commun fait partie de certains fonctionnel Sous-systèmes comprenant plusieurs objets de métadonnées, cette section peut également contenir des procédures et des fonctions d'exportation de service destinées uniquement à être appelées à partir d'autres objets de ce sous-système.
  Pour les modules communs en vrac, il est recommandé de diviser cette section en sous-sections, en fonction de l'attribut fonctionnel. Les sous-sections sont précédées d'un commentaire qu'il est recommandé de publier de la même manière. Par exemple:

1.3. Modèle pour la conception de sections pour les modules d’objet, les gestionnaires, les ensembles d’enregistrements, les traitements, les rapports, etc.:

• La section "Interface de programme" contient les procédures et fonctions d'exportation destinées à être utilisées dans d'autres modules de configuration ou d'autres programmes (par exemple, via une connexion externe). Il n'est pas nécessaire de placer dans cette section les fonctions et procédures d'exportation destinées à être appelées uniquement à partir des modules de l'objet lui-même, de ses formulaires et de ses commandes. Par exemple, les procédures permettant de renseigner la partie table d'un document appelée à partir du traitement de remplissage dans le module objet et du formulaire de document dans le gestionnaire de commandes de formulaire ne constituent pas un module d'interface de programme. sont appelés uniquement dans le module lui-même et à partir des formes du même objet. Ils devraient être placés dans la section "Procédures et fonctions utilitaires."
• La section "Gestionnaires d'événements" contient des gestionnaires d'événements pour le module de l'objet ( Prizavisi , PRO , etc.).
• La section "Procédures et fonctions utilitaires" a la même fonction que dans les modules généraux.

1.4. Modèle de conception de section pour les modules de formulaire:

• La section «Gestionnaires d'événements de formulaire» contient les procédures relatives au gestionnaire d'événements de formulaire: Création d'un serveur , Ouverture , etc.
• La section "Gestionnaires d'éléments de formulaire" contient les procédures de traitement des éléments situés dans la partie principale du formulaire (tout ce qui n'est pas lié aux tableaux du formulaire).
• Dans les sections «Gestionnaires d'événements de la table de formulaire <nom de la table de formulaire>», il existe des procédures pour les gestionnaires de la table de formulaire et de ses éléments. Pour les procédures de gestionnaire, chaque table doit avoir sa propre partition.
• La section «Gestionnaires de commandes de formulaire» contient des procédures pour les gestionnaires de commandes de formulaire (dont les noms sont spécifiés dans la propriété Action des commandes de formulaire).
• La section "Procédures et fonctions utilitaires" a la même fonction que dans les modules généraux.

Voir aussi: Règles pour la création de modules de formulaire

2. Exigences générales pour les sections de modules logiciels.

2.1. L'en-tête de module est un commentaire au tout début du module. L'en-tête du module fournit une brève description et les conditions d'application.
Par exemple:

Pour les modules de formulaire, il est recommandé de placer une description des paramètres de formulaire dans l'en-tête.

2.2. Section de description de variable . Les noms de variables sont attribués en fonction du général règles de nom de variable , et leur utilisation est décrite dans l'article. Utilisation de variables globales dans des modules logiciels .

Toutes les variables de module doivent être accompagnées d'un commentaire suffisant pour comprendre leur objectif. Il est recommandé de placer le commentaire dans la même ligne que celle où la variable est déclarée.
Exemple:

2.3. Interface logicielle Les procédures et fonctions d'exportation qui composent son interface de programmation sont placées immédiatement après la description des variables. Ces procédures et fonctions sont destinées à être utilisées par d'autres objets de configuration ou d'autres programmes (par exemple, via une connexion externe), elles doivent donc être situées à un «endroit visible» dans le module.

Voir aussi: Description des procédures et des fonctions.

2.4.1 Gestionnaires d'événements de formulaire, commandes et éléments de formulaire . Avant les procédures et les fonctions de service dans le module de formulaire, les gestionnaires d’événements du formulaire sont localisés, ainsi que les gestionnaires d’événements pour les commandes et les éléments de formulaire.

Recommandation méthodique (conseils utiles)

Il est recommandé de regrouper les gestionnaires d'un élément de formulaire, en respectant l'ordre de leur suivi dans le panneau de propriétés de l'éditeur de formulaire. dans le configurateur .

2.4.2. Chaque événement doit avoir sa propre procédure de gestionnaire. Si les mêmes actions doivent être effectuées lorsque des événements se produisent dans différents éléments du formulaire:

• créer une procédure séparée (fonction) qui effectue les actions nécessaires

• pour chaque élément de formulaire, créez un gestionnaire distinct avec le nom par défaut

• appelez la procédure requise (fonction) à partir de chaque gestionnaire.

Par exemple, faux:

correct:

Cette exigence est due au fait que la logique des procédures du gestionnaire d'événements n'est pas destinée à être utilisée dans le code du module, mais est directement appelée par la plate-forme. Le mélange de ces deux scénarios dans une procédure complique inutilement sa logique et réduit sa robustesse (au lieu du scénario d'appel envisagé - lors d'un événement de la plate-forme - le code de procédure doit compter sur d'autres appels directs à partir du code).

2.5. Les gestionnaires d'événements pour les modules d'objets et le gestionnaire d'objets sont placés après l'exportation, mais avant les procédures de l'utilitaire et les fonctions du module.

Recommandation méthodique (conseils utiles)

Il est recommandé de placer les gestionnaires, en suivant l'ordre dans la description de la langue incorporée.

2.6 Les procédures utilitaires et les fonctions de module qui ne sont pas des gestionnaires d'événements, mais qui constituent l'implémentation interne d'un module, sont placées dans le module à côté des gestionnaires d'événements.

Dans les cas où un module commun fait partie d'un sous-système fonctionnel comprenant plusieurs objets de métadonnées, cette section peut également contenir des procédures et des fonctions d'exportation de service destinées uniquement à être appelées à partir d'autres objets de ce sous-système.

Il est recommandé de regrouper les procédures et les fonctions liées par nature ou par logique de travail. Il n’est pas recommandé de regrouper explicitement les procédures et les fonctions du module dans un serveur, un client et des fonctions sans contexte, car un tel ordre «technologique» complique la compréhension de la logique du module, attirant ainsi l’attention du développeur sur les détails de son implémentation.

2.7 La section d’initialisation contient des instructions qui initialisent les variables du module ou de l’objet (formulaire). Par exemple:

Autres matériaux sur le sujet:
mise à jour de la base de données . gestionnaires d'événements . interface logicielle . manutentionnaires . procédures . motif . titre . fin de procédure . fonctions . interface . description . presse-papier . copier . section . échange . des formes . un objet . l'élément . configuration . des configurations . document

Matériaux de la section: 1C: Enterprise 8.2 / Développeurs / Accords lors de l'écriture de code

Autres matériaux sur le sujet:

Description des procédures et fonctions

Caractéristiques de la mise à l'échelle pour l'objet sélectionné

Transfert de configurations sur la plate-forme 1C: Enterprise 8.2 vers la plate-forme 1C: Enterprise 8.3 sans mode de compatibilité avec la version 8.2

Noms des procédures et fonctions

Utiliser le mode privilégié

Nous trouvons: la structure du module 1c est , procédures et fonctions de service , module, procédure d'appel du module gestionnaire 1c 8 2, comment appeler une procédure à partir d'un autre module 1c, en-tête de module en anglais, 1c à partir d'une procédure de module d'appel de formulaire de traitement, 1c 8 2 appeler une procédure à partir du module gestionnaire, 1