1.Préface

Ce document vise principalement à fournir aux développeurs Delphi un standard d'écriture de code source, ainsi qu'un standard de dénomination pour les programmes et les fichiers, afin qu'ils puissent avoir un format cohérent à suivre lors de la programmation. De cette façon, chaque programmeur écrit du code qui peut être compris par les autres.

2. Spécifications d'écriture du programme source

2.1. Règles générales de formatage du code source

1).

L'indentation signifie deux espaces entre chaque niveau. Ne placez pas de caractères de tabulation dans le code source. En effet, la largeur du caractère de tabulation varie en fonction des différents paramètres et utilitaires de gestion de code (impression, documentation, contrôle de version, etc.).

En utilisant le menu Outils | Environnement, sur la page Général de la boîte de dialogue Options d'environnement, décochez les cases Utiliser le caractère de tabulation et Remplissage facultatif afin que les caractères de tabulation ne soient pas enregistrés.

2). Marge

Les marges sont définies sur 80 caractères. Le code source ne dépasse généralement pas la marge en écrivant un mot, mais cette règle est plus souple. Dans la mesure du possible, les instructions de plus d'une ligne doivent être entourées de virgules ou d'opérateurs. Après un saut de ligne, il doit être mis en retrait de deux caractères.

3) déclaration de début...de fin

L'instruction de début doit figurer sur une ligne distincte. Par exemple, la première ligne ci-dessous est incorrecte, mais la deuxième ligne est correcte :

for i:=0 à 10 do start // Faux, start et for sont sur la même ligne

pour i:=0 à 10 do // Oui, commence sur une autre ligne

commencer

Un cas particulier de cette règle est lorsque start fait partie d'une instruction else, par exemple :

si une instruction = alors

commencer

.

fin

sinon commencer

Une autre déclaration ;

fin;

Remarque : L'instruction de fin se trouve toujours sur une ligne distincte. Lorsque le début ne fait pas partie d'une instruction else, l'instruction de fin correspondante est indentée du même montant que l'instruction de début.

4).Remarques

Nous utilisons généralement des commentaires de bloc de type "{...}". Les commentaires de bloc de type "(*...*)" précédents sont utilisés pour commenter temporairement le code inutilisé. À partir de Delphi 2, la ligne "//" est prise en charge. commentaires, si vous décidez de ne pas prendre en charge les versions inférieures à Delphi 2.0, vous pouvez utiliser le commentaire "//".

2.2. Spécifications et utilisation du format d'instruction Object Pascal

1). Supports

Il n'y a pas d'espace entre le crochet ouvrant et le caractère suivant. De même, il n’y a pas d’espace entre le crochet fermant et le caractère précédent. L'exemple suivant montre les espaces corrects et incorrects.

CallPRoc( Paramètre ); // Erreur !

CallProc(Aparamètre); // Correct !

N'incluez pas de parenthèses supplémentaires dans les déclarations. Dans le code source, les parenthèses ne sont utilisées que lorsqu'elles sont vraiment nécessaires. Les exemples suivants illustrent une utilisation correcte et incorrecte :

si (I=42) alors // Erreur, les parenthèses sont redondantes

si (I=42) ou (J=42) alors // Correct, il faut utiliser des parenthèses

2) Mots et mots-clés réservés

Les mots et mots-clés réservés dans le langage Pascal Objet sont toujours entièrement en minuscules. Voici une liste de mots réservés Delphi 5 :

3). Procédures et fonctions

(1).Format

Les noms de procédures doivent commencer par une lettre majuscule et être décalés pour améliorer la lisibilité. Ce qui suit est une manière incorrecte d’écrire :

procédure, ce nom de routine est mal formaté ;

Changez-le simplement par ceci :

procédure ThisIsMuchMoreReadableRoutineName ;

(2). Paramètres formels

(1)Format

Dans la mesure du possible, les paramètres du même type doivent être regroupés :

procédure Foo(Param1,Param2,Param3:Imteger;Param4:string);

(2) Ordre des paramètres

L'ordre des paramètres formels dépend principalement des règles d'appel du registre. Le paramètre le plus couramment utilisé doit être le premier paramètre, disposé de gauche à droite par ordre de fréquence d'utilisation. Les paramètres d’entrée précèdent les paramètres de sortie. Les paramètres avec une large plage doivent être placés avant les paramètres avec une petite plage. Par exemple:

SomeProc (aPlanet, aContinent, aCountry, aState, aCity).

Certaines font exception. Par exemple, lors du traitement des événements, le paramètre Sender de type TObject est souvent le premier paramètre à être transmis.

(3) Paramètres constants

Pour éviter que les paramètres de type enregistrement, tableau, chaîne courte ou interface ne soient modifiés par la procédure, le paramètre formel doit être marqué Const. De cette façon, le compilateur générera du code de la manière la plus efficace, garantissant que les paramètres transmis sont immuables.

Si d'autres types de paramètres ne devraient pas être modifiés par la procédure, ils peuvent également être marqués Const. Même si cela n'a aucun impact sur l'efficacité, cela donne plus d'informations à l'appelant de la procédure.

4).Variables

(1).Variables locales

Les variables locales sont utilisées à l'intérieur de la procédure. Si nécessaire, les variables doivent être initialisées immédiatement à l'entrée de la procédure. Les variables locales de type AnsiString sont automatiquement initialisées à une chaîne vide, les variables de type interface locale et dispinterface sont automatiquement initialisées à nil et les variables locales de type Variant et OleVariant sont automatiquement initialisées à Unassigned.

(2).Variables globales

L'utilisation de variables globales est généralement déconseillée. Cependant, cela est parfois nécessaire. Même ainsi, les variables globales doivent être limitées aux environnements où elles sont nécessaires. Par exemple, une variable globale peut être globale uniquement pour la partie implémentation de l'unité.

Les données globales qui seront utilisées par de nombreuses unités doivent être déplacées vers une unité commune et utilisées par tous les objets. Les données globales peuvent être directement initialisées à une valeur lorsqu'elles sont déclarées. Notez que toutes les variables globales sont automatiquement initialisées à zéro, n'initialisez donc pas les variables globales à des valeurs nulles telles que 0, nil ou Unassigned. Les variables globales initialisées à zéro n'occupent aucun espace dans le fichier .EXE. Les données initialisées à zéro sont stockées dans un segment de données virtuelles, et le segment de données virtuelles n'alloue de la mémoire qu'au démarrage de l'application. Les données globales initialisées différentes de zéro occupent de l'espace dans le fichier .EXE.

5). Tapez

(1). Règles de capitalisation

Les identifiants de type sont des mots réservés et doivent être tous en minuscules. Les types d'API Win32 sont souvent en majuscules et suivent les règles des noms de types spécifiques dans Windows.pas ou d'autres unités API. Pour les autres noms de variables, la première lettre doit être en majuscule et les autres lettres doivent être en casse alternée. Voici quelques exemples :

var

MaChaîne : chaîne ; // mots réservés

WindowsHandle : HWND ; // Type d'API Win32

I : Entier ; //Identifiant de type introduit dans l'unité Système.

(2).Type à virgule flottante

L'utilisation du type Real est déconseillée car réservée uniquement à la compatibilité avec l'ancien code Pascal. Normalement, Double doit être utilisé pour les nombres à virgule flottante. Double peut être optimisé par le processeur et est un format de données standard défini par l'IEEE. Extend peut être utilisé lorsqu’une portée plus grande que celle fournie par Double est requise. Extend est un type spécifique à Intel et n'est pas pris en charge par Java. Lorsque le nombre physique d'octets de la variable à virgule flottante est important (peut-être en utilisant un langage différent pour écrire la DLL), Single doit être utilisé.

(3).Variant et OleVariant

Il n'est généralement pas recommandé d'utiliser Variant et OleVariant. Cependant, ces deux types sont nécessaires à la programmation lorsque le type de données n'est connu qu'au moment de l'exécution (souvent dans les applications COM et de base de données). Lorsque vous effectuez une programmation COM telle que l'automatisation des contrôles ActiveX, vous devez utiliser OleVariant ; pour la programmation non-COM, vous devez utiliser Variant. En effet, Variant peut enregistrer efficacement les chaînes natives de Delphi, tandis qu'OleVariant convertit toutes les chaînes en chaînes OLE (c'est-à-dire les chaînes WideChar) et n'a pas de fonction de comptage de références.

6). Déclaration

(1).Si déclaration

Dans une instruction if/then/else, le cas d'exécution le plus probable doit être placé dans la clause then, et le cas le moins probable doit être placé dans la clause else. Pour éviter de nombreuses instructions if, utilisez plutôt des instructions case. S'il y a plus de 5 niveaux, n'utilisez pas d'instructions if. Veuillez plutôt utiliser une méthode plus claire. N'utilisez pas de parenthèses supplémentaires dans les instructions if.

S'il y a plusieurs conditions à tester dans une instruction if, elles doivent être classées de droite à gauche par ordre de complexité de calcul. Cela permet au code de tirer pleinement parti de la logique d'estimation des courts-circuits du compilateur. Par exemple, si Condition1 est plus rapide que Condition2 et que Condition2 est plus rapide que Condition3, l'instruction if doit généralement être construite comme ceci :

si Condition1 et Condition2 et Condition3 alors

S'il y a de fortes chances que la Condition3 soit fausse, en utilisant la logique d'estimation de court-circuit, nous pouvons également mettre la Condition3 au premier plan :

si Condition3 et Condition1 et Condition2 alors

(2).

(1) Aperçu

Les constantes de chaque cas dans l'instruction case doivent être classées par ordre numérique ou alphabétique. L'instruction d'action pour chaque situation doit être courte et ne doit généralement pas dépasser 4 à 5 lignes de code. Si l'action est trop complexe, le code doit être placé dans une procédure ou une fonction distincte. La clause else de l'instruction Case n'est utilisée que pour les cas par défaut ou la détection d'erreurs.

(2) Format

Les instructions case suivent les règles normales d’indentation et de dénomination.

(3).

Il est recommandé de ne pas utiliser la procédure Exit pour quitter la boucle while. Si nécessaire, une condition de boucle doit être utilisée pour quitter la boucle. Tout le code qui initialise la boucle while doit être situé avant l'entrée while et ne doit pas être séparé par des instructions non pertinentes. Tout travail auxiliaire pour l'entreprise doit être effectué immédiatement après le cycle.

(4). pour la déclaration

Si le nombre de boucles est déterminé, une instruction for doit être utilisée à la place d'une instruction while.

(5).répéter la déclaration

L'instruction repeat est similaire à une boucle while et suit les mêmes règles.

(6). avec déclaration

(1) Aperçu

L'instruction with doit être utilisée avec prudence. Évitez d'abuser des instructions with, en particulier lorsque vous utilisez plusieurs objets ou enregistrements dans une instruction with. Par exemple:

avec Record1,Record2 faire

Ces situations peuvent facilement dérouter les programmeurs et rendre le débogage difficile.

(2) Format

L'instruction with suit également les règles de ce chapitre en matière de dénomination et d'indentation.

7). Gestion structurée des exceptions

(1).

La gestion des exceptions est principalement utilisée pour corriger les erreurs et protéger les ressources. Cela signifie que partout où des ressources sont allouées, il faut essayer... enfin de garantir que les ressources soient libérées. Cependant, des exceptions sont faites si des ressources sont allouées/libérées dans la partie initiale/finale de l'unité ou dans le constructeur/destructeur de l'objet.

(2). Utilisation de try...enfin

Dans la mesure du possible, chaque allocation de ressources doit correspondre à une structure try...finally. Par exemple, le code suivant peut provoquer une erreur :

SomeClass1 := TSomeClass.Create;

SomeClass2 := TSomeClass.Create;

essayer

{ faire du code }

enfin

UneClasse1.Free ;

SomeClass2.Free;

fin;

Une solution sûre pour l’allocation des ressources ci-dessus est :

SomeClass1 := TSomeClass.Create;

essayer

SomeClass2 := TSomeClass.Create;

essayer

{ faire du code }

enfin

SomeClass2.Free;

fin;

enfin

UneClasse1.Free ;

fin;

(3). Utilisation de try...sauf

Si vous souhaitez effectuer une tâche lorsqu'une exception se produit, vous pouvez utiliser try...sauf. Habituellement, il n'est pas nécessaire d'utiliser try...sauf pour simplement afficher un message d'erreur, car l'objet application peut le faire automatiquement en fonction du contexte. Si vous souhaitez activer la gestion des exceptions par défaut dans la clause, vous pouvez déclencher à nouveau l'exception.

(4). Utilisation de try...sauf...sinon

L'utilisation de try...sauf avec une clause else est déconseillée car cela bloquera toutes les exceptions, y compris les exceptions que vous n'êtes pas prêt à gérer.

3. Convention de dénomination

3.1. Procédure et fonction

1).Nom

Les noms de procédures et de fonctions doivent être significatifs. Il est préférable de préfixer le nom du processus d'exécution d'une action avec le verbe qui exprime l'action. Par exemple:

procédure FormatHardDrive ;

Le nom de la procédure de définition des valeurs des paramètres d'entrée doit être préfixé par Set, par exemple :

procédure SetUserName ;

Le nom de la procédure d'obtention d'une valeur doit être préfixé par Get, par exemple :

fonction GetUserName:string;

2).Paramètres formels

Le nom de tous les paramètres formels doit exprimer son objectif. Le cas échéant, le nom du paramètre formel est de préférence préfixé par la lettre a, par exemple :

procédure SomeProc(aUserName:string; aUserAge:integer);

Le préfixe a est nécessaire lorsque le nom du paramètre porte le même nom qu'un attribut ou un champ de classe.

3).Conflit de dénomination

Lorsque deux unités contiennent des procédures portant le même nom, si la procédure est appelée, la procédure de l'unité qui apparaît plus tard dans la clause Uses est réellement appelée. Pour éviter cela, ajoutez le nom de l'unité souhaitée avant le nom de la méthode, par exemple :

SysUtils.FindClose(SR);

ou Windows.FindClose(Handle);

3.2.

Le nom d'une variable doit exprimer son objectif. Les variables de contrôle de boucle sont souvent des lettres simples, telles que I, J ou K. Vous pouvez également utiliser un nom plus significatif, tel que UserIndex. Les noms de variables booléennes doivent clairement indiquer la signification des valeurs Vrai et Faux.

1). Variables locales

Les variables locales suivent les règles de dénomination des autres variables.

2). Variables globales

Les variables globales commencent par une lettre majuscule « G » et suivent les règles de dénomination des autres variables.

3.3.Tapez

3.3.1.Types généraux

1).Type d'énumération

Le nom du type d'énumération doit représenter l'objectif de l'énumération. Le caractère T doit être préfixé avant le nom pour indiquer qu'il s'agit d'un type de données. Le préfixe de la liste d'identifiants du type énumération doit contenir 2 à 3 caractères minuscules à associer les uns aux autres. Par exemple:

TSongType=(stRock, stClassical, stCountry, stAlternative, stHeavyMetal, stRB) ;

Le nom d'une instance de variable d'un type énumération est le même que le type, mais sans le préfixe T. Vous pouvez également donner à la variable un nom plus spécial, tel que : FavoriteSongTypel, FavoriteSongType2, etc.

3.3.2. Type construit

1).Type de tableau

Le nom du type de tableau doit exprimer le but du tableau. Les noms de types doivent être préfixés par la lettre « T ». Si vous souhaitez déclarer un pointeur vers un type tableau, vous devez le préfixer de la lettre P et le déclarer avant la déclaration de type. Par exemple:

taper

PCycleArray = ^TCycleArray;

TCycleArray=array[1..100] d'entier ;

En fait, une instance variable d'un type tableau porte le même nom que le type, mais sans le préfixe "T".

2).Type d'enregistrement

Le nom du type d'enregistrement doit exprimer l'objectif de l'enregistrement. Les noms de types doivent être préfixés par la lettre T. Si vous souhaitez déclarer un pointeur vers un type d'enregistrement, vous devez le préfixer de la lettre P et le déclarer avant la déclaration de type. Par exemple:

taper

PEmployé = ^TEmployé;

Employé = enregistrement

NomEmployé : chaîne ;

Taux employé : double ;

fin;

3.3.3. Type de classe (Classe)

1). Dénomination et format

Le nom de la classe doit exprimer le but de la classe. Généralement, la lettre "T" doit être ajoutée avant le nom de la classe. S'il s'agit d'une classe d'interface, alors "I" doit être ajouté avant le nom de la classe. Le nom de la classe d'exception d'erreur doit être ajouté avec "E". et le type de référence de classe (type de référence de classe) doit être ajouté avant le nom de la classe. Ajoutez « Classe » après le nom. Par exemple:

taper

TClient = classe(TObject);

IClient = interface ;

TCustomerClass = classe de TCustomer

ECustomerException = classe (Exception);

Le nom d'instance d'une classe est généralement le même que le nom de classe, sans le préfixe « T ».

var

Client : TClient ;

Remarque : Pour la dénomination des composants, voir "Types de composants".

2).Champ

(1) Dénomination et format

La dénomination des champs suit les mêmes règles que celle des variables, sauf que le préfixe F est ajouté pour indiquer qu'il s'agit d'un champ.

(2) Visibilité

Tous les champs doivent être privés. Si vous souhaitez accéder à un champ en dehors de la portée d'une classe, vous pouvez le faire à l'aide des attributs de classe.

3).Méthode

(1) Dénomination et format

La dénomination des méthodes suit les mêmes règles que les procédures et les fonctions.

(2) Méthode statique

Les méthodes statiques doivent être utilisées lorsque vous ne souhaitez pas qu'une méthode soit remplacée par des classes dérivées.

(3) Méthode virtuelle (virtuelle) et méthode dynamique (dynamique)

Lorsque vous souhaitez qu'une méthode soit remplacée par des classes dérivées, vous devez utiliser des méthodes virtuelles. Si une méthode de classe doit être utilisée directement ou indirectement par plusieurs classes dérivées, des méthodes dynamiques (dynamic) doivent être utilisées. Par exemple, si une classe contient une méthode fréquemment remplacée et possède 100 classes dérivées, la méthode doit être définie comme dynamique, ce qui peut réduire la surcharge de mémoire.

(4) Méthode abstraite (résumé)

Si une classe doit créer des instances, n'utilisez pas de méthodes abstraites. Les méthodes abstraites ne peuvent être utilisées que dans des classes de base qui ne créent jamais d'instances.

(5) Méthode d'accès aux attributs

Toutes les méthodes d'accès aux propriétés doivent être définies dans la partie privée ou protégée de la classe. Les méthodes d'accès aux propriétés suivent les mêmes règles que les procédures et les fonctions. Les méthodes utilisées pour la lecture doivent être préfixées par « Get », les méthodes utilisées pour l'écriture doivent être préfixées par « Set » et avoir un paramètre appelé Value dont le type est le même que le type de la propriété. Par exemple:

TSomeClass = classe (TObject)

privé

fsomeField : entier ;

protégé

fonction GetSomeField : entier ;

procédure SetSomeField (Valeur : Entier);

publique

propriété SomeField : entier lu GetSomeField écrit SetSomeField ;

fin;

Bien que cela ne soit pas obligatoire, il est recommandé d'utiliser des méthodes d'accès en écriture pour accéder aux propriétés représentant les champs privés.

4).Attributs

Les propriétés servent d'accesseurs aux champs privés et suivent les mêmes règles de dénomination que les champs, sauf sans le préfixe F. Les noms de propriétés doivent être des noms et non des verbes. Les propriétés sont des données et les méthodes sont des actions. Les noms de propriétés de tableau doivent être au pluriel, tandis que les propriétés générales doivent être au singulier.

3.3.4.Type de composant

1). Normes de dénomination des types de composants

La dénomination des composants est similaire à la dénomination des classes, sauf qu'en cas de conflit avec d'autres noms de composants, vous pouvez ajouter un préfixe à 3 caractères pour identifier une entreprise, un individu ou une autre entité. Par exemple, un composant d'horloge peut être déclaré comme ceci :

TddgClock = classe (TComponent)

Notez que les trois caractères du préfixe doivent être en minuscules.

2). Règles de dénomination des instances de composants

Le nom de l'instance de composant doit pouvoir décrire sa signification réelle. La convention de dénomination utilise ici une convention de dénomination de préfixe hongrois modifiée. La raison pour laquelle vous utilisez un préfixe au lieu d'un suffixe est qu'il est plus facile de rechercher le nom du composant dans l'inspecteur d'objets et l'explorateur de code que de rechercher le type du composant. Dans cette norme, le nom d'instance de composant se compose de deux parties : le préfixe et l'identifiant d'attribut.

(1). Préfixe du composant

Le préfixe d'un composant est généralement une abréviation du type de composant. Voir les préfixes des composants dans le tableau ci-dessous :

Comme indiqué ci-dessus, le préfixe de type de composant provient de l'analyse des propriétés de type qui décrivent le composant. En règle générale, les règles suivantes décrivent comment définir un préfixe de type de composant :

• Supprimez le préfixe T des noms de types de composants. Par exemple, TButton devient Button.
• Supprimez toutes les voyelles sauf la première voyelle. Par exemple, Button devient bttn et Edit devient edt.
• Lettres doubles compressées. Par exemple, bttn devient btn.
• En cas de conflit, une voyelle est ajoutée au préfixe d'un élément. Par exemple, ajoutez une voyelle au préfixe du composant TBatton et remplacez-la par batn pour la distinguer du préfixe de TButton.

• Toutefois, les règles ci-dessus doivent d'abord garantir que le nom du préfixe doit être conforme à la coutume, afin que le nom puisse être compris. Par exemple, le préfixe du contrôle TDDEClientConv constitue une exception.

Remarque : Le préfixe d'un composant sert à indiquer le type de composant, qu'il s'agisse d'un bouton, d'une étiquette, etc., il n'est donc pas nécessaire de créer un préfixe de composant pour chaque classe de composant spéciale. Par exemple, le préfixe de composant de. TMyButton est toujours bloqué.

(2). Nom d'identification de la propriété du composant

Le nom d'identification de la propriété du composant est une description de l'intention du composant. Par exemple, une instance du composant TButton utilisée pour fermer un formulaire pourrait être nommée btnClose. Une instance du composant modifier le nom peut être nommée edName.

3.3.5. Types de formulaires et de boîtes de dialogue

1). Normes de dénomination pour les types de formulaires

Le nom du formulaire ou du type de boîte de dialogue doit exprimer l'objectif du formulaire, préfixé par « Tfrm » pour un formulaire ou « Tdlg » pour une boîte de dialogue, suivi d'un nom descriptif. Par exemple, le nom du type de formulaire À propos est :

TfrmÀ propos = classe (TForm)

Le nom du type du formulaire principal est :

TfrmMain = classe (TForm)

Le nom du type du formulaire de connexion client est :

TfrmCustomerEntry = classe (TForm)

Le nom du type de la boîte de dialogue de connexion est :

TdlgLogin = classe (TForm)

2) Normes de dénomination pour les instances de formulaire

Le nom de l'instance de formulaire est le même que le nom du type correspondant, mais sans le préfixe T. Par exemple, le nom du type de formulaire et de l'instance mentionnés précédemment est :

3). Formulaire créé automatiquement

Sauf raisons particulières, seul le formulaire principal est généré automatiquement. Tous les autres formulaires doivent être supprimés de la liste générée automatiquement dans la boîte de dialogue Options du projet. Pour plus d’informations, consultez les sections suivantes.

4). Fonction d'instanciation de forme modale

Toutes les unités de formulaire doivent contenir des fonctions d'instanciation pour la création, la configuration, l'affichage modal et la publication du formulaire. Cette fonction renverra le résultat de mode renvoyé par le formulaire. Les paramètres transmis à cette fonction suivent les règles de transmission des paramètres. La raison d'une telle encapsulation est de faciliter la réutilisation et la maintenance du code.

Les variables du formulaire doivent être supprimées de l'unité et définies comme variables locales dans la fonction d'instanciation du formulaire (notez que cela nécessite la suppression du formulaire de la liste générée automatiquement dans la boîte de dialogue Options du projet. Veuillez consulter le contenu précédent.

Par exemple, le fichier unité suivant illustre la fonction d'instanciation GetUserData.

Unité UserDataFrm ;

Interface

Utilisations

Windows, messages, SysUtils, classes, graphiques, contrôles, formulaires,

Boîtes de dialogue, StdCtrls ;

Taper

TfrmUserData = classe (TForm)

edtUserName : TEdit ;

edtUserID : TEdit ;

privé

{Déclarations privées}

publique

{Déclarations publiques}

fin;

function GetUserData(var aUserName : String;var aUserID : Integer) : Word ;

mise en œuvre

{$R *.DFM}

function GetUserData(var aUserName : String;var aUserID : Integer) : Word ;

var

frmUserData : TfrmUserData ;

commencer

frmUserData := TfrmUserData.Create(Application);

frmUserData.Caption:='Obtention des données utilisateur';

Résultat : = frmUserData.ShowModal;

si Résultat=mrOK alors

commencer

aUserName := frmUserData.edtUserName.Text;

aUserID := StrToInt(frmUserData.edtUserID.Text);

fin;

enfin

frmUserData.Free;

fin;

fin;

Fin.

5).Cadre de formulaire et formulaire composite

Si une structure de formulaire est trop complexe, elle doit être divisée en un cadre de formulaire principal et plusieurs sous-cadres de formulaire intégrés dans le cadre de formulaire principal. comme:

TfrmMainFrame : TfrmInfoFrame, TfrmEditorFrame

L'objectif principal de l'utilisation des cadres de formulaire est de résoudre le problème de la réutilisation des interfaces et du code, et d'améliorer la cohésion du code unitaire (après division, chaque cadre de formulaire est une unité indépendante), améliorant ainsi la qualité de l'ingénierie logicielle. Vous devez extraire le code lié à l'interface (réutilisable) et le code lié à l'application (non réutilisable).

3.3.6.Type de module de données

1). Normes de dénomination des modules de données

Le nom du type de module de données doit exprimer son objectif et être préfixé par « Tdm » suivi d'un nom descriptif. Par exemple, le nom de type du module de données Client est :

TdmCustomer = classe (TDataModule)

Le nom de type du module de données Commandes est :

TdmOrder = classe (TDataModule)

2). Normes de dénomination pour les instances de module de données

Le nom d'une instance de module de données doit être identique au nom du type correspondant, mais sans le préfixe T. Par exemple, le type de module de données et le nom d'instance précédents sont les suivants :

3.4.Documents

Il est recommandé d'utiliser des informations d'en-tête de fichier structurées dans tous les fichiers source, fichiers de projet et fichiers d'unité. Un en-tête de fichier doit contenir au moins les informations suivantes :

{

Copyright @ Année par auteurs

}

3.4.1.Fichiers du projet

Les noms de fichiers de projet doivent être descriptifs. Par exemple, le nom du projet « The Delphi 5 Developer's Guide Bug Manager » est DDGBugs.dpr et le nom d'un programme d'informations système est SysInfo.dpr.

3.4.2. Fichier de formulaire

Le nom du fichier du formulaire doit exprimer l'objectif du formulaire et comporter le suffixe Frm. Par exemple, le nom de fichier du formulaire À propos est AboutFrm.dfm et le nom de fichier du formulaire principal est MainFrm.dfm.

3.4.3.Fichiers du module de données

Le nom du fichier du module de données doit exprimer le rôle du module de données et avoir un suffixe DM. Par exemple, le nom de fichier du module de données Customers est CustomersDM.dfm.

3.4.4.Fichier du module de données distant

Le nom du fichier du module de données distant doit exprimer l'objectif du module de données distant. Ajoutez le suffixe RDM après le nom. Par exemple, le fichier du module de données distant Customers s'appelle CustomersRDM.dfm.

3.4.5.Fichier unité

1). Unité ordinaire

(1) Nom de l'unité

Les noms des unités doivent être descriptifs. Par exemple, l'unité de formulaire principale de l'application s'appelle MaimFrm.pas.

(2) Clause d'utilisation

La clause Uses de la section Interface doit contenir uniquement les unités requises par cette section. N'incluez pas les noms d'unités qui peuvent être ajoutés automatiquement par Delphi. La clause Uses de la partie Implémentation ne doit contenir que les unités nécessaires à cette partie, et aucune unité supplémentaire.

(3) Partie interface

La section Interface ne doit contenir que des déclarations de types, de variables, de procédures et de fonctions auxquelles les unités externes doivent accéder. De plus, ces déclarations doivent précéder la section Mise en œuvre.

(4) Partie mise en œuvre

La partie Implémentation comprend l'implémentation des types privés, des variables, des procédures et des fonctions de cette unité.

(5) Partie initialisation

Ne placez pas de code fastidieux dans la section Initialisation. Sinon, l’application démarrera très lentement.

(6) Partie finalisation

Assurez-vous de libérer toutes les ressources allouées dans la section Initialisation.

2).Unité de formulaire

Le nom du fichier de l'unité de formulaire est le même que le nom du formulaire correspondant, remplacez simplement le préfixe par le suffixe. Par exemple, le nom d'unité du formulaire À propos est AboutFrm.pas. Le nom de fichier unité du formulaire principal est MainFrm.pas.

3).Unité de module de données

Le nom du fichier d'unité du module de données est identique au nom du module de données correspondant. Par exemple, le nom de l'unité du module de données est CustomersDM.pas.

4).Unité générale

Le nom d'une unité générale doit exprimer son objectif et doit être préfixé par « u ». Par exemple, le nom d'une unité d'outil de débogage pratique est uDebugUtilities.pas, et le nom de l'unité contenant des variables globales est uCustomerGlobals.pas.

Notez que les noms d'unités doivent être uniques au sein d'un projet. Les noms d'unités communes ne peuvent pas avoir le même nom.

5).Unité composante

(1).

Les cellules du composant doivent être placées dans des chemins séparés pour indiquer qu'il s'agit des cellules qui définissent le composant. Ils ne sont généralement pas placés dans le même chemin que le projet. Les noms de fichiers d'unité doivent exprimer leur contenu.

Remarque : consultez « Normes de dénomination pour les types de composants » pour plus d'informations sur les normes de dénomination des composants.

Une cellule de composant ne peut contenir qu'un seul composant principal, à savoir le composant qui apparaît dans la palette de composants. D'autres composants ou objets auxiliaires peuvent également être inclus dans la même unité.

(2). Unité d'enregistrement

Le processus d'enregistrement des composants doit être retiré de l'unité des composants et placé dans une unité distincte. Cette unité d'enregistrement permet d'enregistrer tous les composants, éditeurs de propriétés, éditeurs de composants, assistants, etc.

L'enregistrement des composants doit être effectué dans le package de conception. Par conséquent, les unités d’enregistrement doivent être incluses dans le package de conception plutôt que dans le package d’exécution. Il est recommandé que l'unité d'enregistrement soit nommée ainsi :

xxxReg.pas

Parmi eux, le préfixe de caractère xxx est utilisé pour identifier le nom du package de composants ou l'entreprise, l'individu ou une autre entité. Par exemple, l'unité d'enregistrement est nommée xxxReg.pas.

6). Règles de dénomination des fichiers de package (.dpk)

(1). Package d’exécution et package de conception.

Le package d’exécution doit contenir uniquement les unités requises. Ces éléments de l'éditeur de propriétés et de l'éditeur de composants doivent être placés dans le package au moment de la conception. Les unités d'enregistrement doivent également être incluses dans le package de la phase de conception.

(2). Normes de dénomination des fichiers

La dénomination des packages suit le modèle suivant :

dcliiiDescvvCn.pkg —Package de conception

iiiDescvvCn.pkg — package d'exécution

Parmi eux, iii représente un préfixe de 2 à 3 caractères, utilisé pour identifier les entreprises, les individus ou d'autres éléments qui doivent être identifiés. Desc représente une brève description du package de contrôle ; vv représente le numéro de version du package de contrôle ; package. Vous pouvez choisir en fonction de vos besoins. ;Le préfixe « dcl » indique un package au moment de la conception, sans ce préfixe indique un package au moment de l'exécution ; la lettre « Cn » indique le type de compilateur et le numéro de version du compilateur, par exemple : Delphi5=D5, Delphi4=D4, CBuilder3=C3....

Notez que lib ou std dans le nom du package indique s'il s'agit respectivement d'un package au moment de la conception ou d'un package au moment de l'exécution. Par exemple:

dclrbStdComPSD5.pkg — Package de conception Delphi 5

rbStdCompsD5.pkg — Package d'exécution Delphi 5

4.Outil de formatage automatique du code Delphi

Bien que la plupart des outils de formatage automatique du code puissent vous aider à réorganiser le format du programme source et à mettre à jour la capitalisation des mots réservés et des identifiants, il est préférable de le faire avant d'utiliser le contrôle de version. Si vous avez déjà utilisé le contrôle de version, il est recommandé de ne pas le faire. Utiliser facilement les outils de formatage automatique du code Même s'il reste un espace supplémentaire, l'outil de contrôle de version pensera que la ligne a été modifiée, entraînant ainsi des modifications dans la gestion du programme.