Guide de style Pascal Objet - Par Charles Calvert
(Guide de style de codage Objet Pascal - Traduit par : Tommy Tong)
Nous reconnaissons que de nombreux studios ou individus bien établis ont leurs propres pratiques de programmation qui diffèrent de celles décrites dans cet article. Cependant, nous vous recommandons fortement d'utiliser un outil pour convertir votre code en code de style Borland, puis de le soumettre à Borland, Projet JEDI ou tout autre référentiel de code source public. Nous ne voulons pas vous obliger à changer vos habitudes, mais nous insistons pour que tout le code qui fonctionne avec les produits Borland suive les habitudes décrites dans cet article.
Object Pascal est un magnifique langage de conception. Une forte lisibilité est l’un de ses avantages. Les normes conçues dans cet article amélioreront la lisibilité du code Object Pascal. Lorsque les développeurs suivront ces habitudes simples démontrées dans cet article, elles deviendront également des standards, ce qui profitera à tous les développeurs Delphi utilisant un style de codage unifié et lisible. Les efforts visant à appliquer ces normes augmenteront la valeur du code source pour les développeurs, en particulier pendant les phases du cycle de maintenance et de débogage.
Bien que nous croyions et admirions le style promu dans cet article, nous ne l’approuvons pas nécessairement car il est bon en soi et mauvais chez les autres. Cependant, nous pensons que la norme suivie par la grande majorité des développeurs a sa validité, c'est pourquoi nous soutenons et maintenons toujours ce style. Le cerveau humain s’adapte constamment aux normes et trouve des moyens d’organiser rapidement des modèles familiers afin que leur signification puisse être comprise rapidement et efficacement. C'est cette exigence qui établit des normes qui permettront à un grand nombre de personnes de lire le code aussi facilement que possible. Si nos directives ne vous semblent pas familières pour la première fois, nous vous demandons de vous y tenir pendant un certain temps et vous constaterez que vous vous y habituerez. Ou, si vous préférez, vous pouvez conserver votre propre style et le convertir via un programme conforme à nos normes, puis soumettre votre code à Borland ou à d'autres référentiels.
Certains éditeurs de texte, comme Visual SlickEdit, peuvent vous aider à formater votre code dans un certain style.
Un formateur gratuit développé par Egbert van Nes est disponible sur :
http://www.slm.wau.nl/wkao/delforexp.html
Un autre programme commercial pour Delphi est CrackerJax :
http://www.kineticssoftware.com/html/products.html
-------------------------------------------------- ----
1.0 Introduction
Cet article n'est pas une tentative de définir des règles de syntaxe pour le langage Object Pascal. Par exemple : il est illégal de mettre le sceau « ; » devant else ; le compilateur n'autorise pas cette utilisation. Je ne montrerai donc pas les règles de grammaire dans cet article. Cet article vise à définir un comportement approprié lorsque le langage offre des choix. Je garde généralement le silence lorsqu’il n’existe qu’une seule méthode de contrôle.
1.1 Contexte
Les directives présentées dans cet article sont basées sur une partie du code source de Delphi. Le code source de Delphi suit exactement ces directives. Si vous constatez une violation de ces principes, ce sont ces principes, et non le code source incertain, qui devraient vous servir de ligne directrice. Cependant, vous pouvez utiliser le code original en complément de ces principes, au moins pour vous aider à vous faire une idée générale de la forme de votre propre code.
1.2 Merci
Les formats présentés dans cet article sont basés sur des travaux effectués pour définir des normes de style pour le langage Java. Java n'a aucune influence sur les règles de formatage du code source Object Pascal, mais la documentation disponible sur le site Web de Sun constitue la base de cet article. À certains endroits particuliers, le style et le format de cet article ont été grandement inspirés par « Un guide de style de codage pour la programmation Java WorkShop et Java Studio » (Achut Reddy, « Guide de codage pour Java WorkShop et Java Studio »). L'article peut être consulté à cette URL : http://www.sun.com/workshop/java/wp-coding
L'équipe Delphi a apporté une contribution significative à la réalisation de cet article. En fait, sans leur aide, cet article n'aurait pas été achevé.
2.0 Fichiers sources
Le code source Object Pascal est principalement divisé en fichiers source uniques et fichiers de projet, et ils suivent tous la même convention. Les fichiers de projet Delphi ont une extension .DPR. C'est le fichier principal du projet. Tout fichier unité utilisé dans un projet a une extension .PAS. D'autres fichiers, tels que les fichiers batch, les fichiers HTML ou les DLL, peuvent également jouer un rôle dans le projet, mais cet article ne couvre que les fichiers de projet et les fichiers unitaires.
2.1 Dénomination du fichier source
Object Pascal prend en charge les noms de fichiers longs. Si vous utilisez plusieurs mots pour former un seul nom, il est préférable d'utiliser une majuscule initiale pour chaque mot : MyFile.pas. Ceci est considéré comme une parenthèse ou camelCase. Les extensions doivent être en minuscules. Pour des raisons historiques, le code source de Delphi utilise souvent le modèle de dénomination 8:3, mais les développeurs n'ont pas besoin d'être limités par les règles ci-dessus et de se tourner vers l'utilisation de l'équipe Delphi.
Si vous traduisez un fichier d'en-tête C/C++, le fichier Pascal que vous traduisez doit conserver le même nom de fichier principal que le fichier d'en-tête C/C++ et utiliser .PAS comme extension. Par exemple : Windows.h -> Windows.pas. Si la syntaxe Pascal vous oblige à combiner plusieurs fichiers d'en-tête en un seul fichier d'unité, alors le nom du fichier d'en-tête qui contient les autres fichiers d'en-tête sera utilisé comme nom du nouveau fichier d'unité. Par exemple : Windows.h contient le fichier WinBase.h, alors le nouveau fichier unité est nommé Windows.pas.
2.2 Organisation du fichier source
Tous les fichiers unitaires Object Pascal doivent contenir les éléments suivants dans l'ordre suivant :
Commentaires sur les droits d'auteur/blocage d'identité
nom de l'unité
segment d'interface
Partie mise en œuvre
Un terminateur « fin ».
Il doit y avoir au moins une ligne vide entre chaque section.
Les autres éléments doivent être structurés dans l’ordre que vous jugez le plus approprié. Mais le copyright doit apparaître au tout début du fichier, puis le nom de l'unité, puis les définitions conditionnelles, les directives du compilateur ou les instructions d'inclusion, et enfin la clause using :
{************************************************* * *****}
{ }
{ Bibliothèque de composants visuels Borland Delphi }
{ }
{ Copyright (c) 1995,98 Inprise Corporation }
{ }
{************************************************* * *****}
Boutons de l'unité ;
{$S-,W-,R-}
{$C PRÉCHARGEMENT}
interface
utilise
Windows, Messages, Classes,
Contrôles, formulaires, graphiques,
StdCtrls, ExtCtrls, CommCtrl ;
Si vous placez la section type avant la section const, ou mélangez les deux, cela n'a aucun effet.
La partie implémentation doit d'abord écrire l'implémentation, puis la clause using, puis d'autres déclarations d'inclusion ou d'autres indicateurs :
mise en œuvre
utilise
Consts, SysUtils, ActnList,
Liste Img ;
{$R BOUTONS.RES}
2.2.1 Commentaires sur les droits d'auteur/blocage d'identité
Chaque fichier source doit commencer par un commentaire de bloc contenant des informations sur la version et un avis de droit d'auteur standard. Les informations sur la version peuvent ressembler à ceci :
{************************************************* * *****}
{ }
{ Widgets à gogo }
{ }
{ Copyright (c) 1995,98 Votre entreprise }
{ }
{************************************************* * *****}
La mention de droit d'auteur doit contenir au moins les lignes suivantes :
Copyright (C) Année Propriétaire du droit d'auteur
Si vous êtes un tiers développant un logiciel pour Borland, vous pouvez ajouter votre propre nom à la fin du copyright :
{************************************************* * *****}
{ }
{ Bibliothèque de composants visuels Borland Delphi }
{ Copyright (c) 1995,99 Borland International }
{ Créé par le projet JEDI }
{ }
{************************************************* * *****}
2.2.2 déclaration d'unité
Chaque fichier unité doit avoir une déclaration d'unité. unit est un mot réservé, il doit donc être en minuscule. Le nom de l'unité peut être en casse mixte, mais doit être le même que le nom du fichier de l'unité. Par exemple:
unité MonUnité ;
Ensuite, le nom du fichier unité doit être MyUnit.pas. Dans le système de fichiers, il sert d'entrée pour ce fichier.
2.2.3 Déclaration d'utilisation
Au sein d'une unité, les déclarations d'utilisation doivent être amorcées avec des utilisations plus petites. Le nom de l'unité référencée suit la convention de capitalisation utilisée lorsqu'elle est définie dans sa propre unité :
utiliseMonUnité ;
Chaque nom d'unité est séparé du nom d'unité adjacent par une virgule et le dernier nom d'unité est suivi d'un point-virgule :
utilise
Windows, SysUtils, Classes, Graphiques, Contrôles, Formulaires,
TypeInfo ;
Il est également correct d'ajouter le nom de l'unité à partir de la ligne d'utilisation suivante et d'ajouter le nom de l'unité directement après les utilisations.
utilise Windows, SysUtils, Classes, Graphiques, Contrôles, Formulaires,
TypeInfo ;
Vous pouvez formater votre liste de noms d'unités pour qu'elle respecte la limite de 80 caractères ou pour avoir une ligne par nom d'unité.
2.2.4 Définitions de classes et d'interfaces
Les définitions de classe commencent par deux espaces, suivis d'un préfixe « T ». Le préfixe doit être en majuscule et chaque mot intégré doit commencer par une majuscule. N'utilisez pas le caractère de tabulation "Tab" dans le code source Object Pascal. exemple:
TMaClasse
Faites suivre l'identifiant d'un espace, puis d'un signe égal, puis du mot classe, qui doit être en minuscule :
TMaClasse = classe
Si votre classe hérite d'un ancêtre, vous devez ajouter des crochets gauche et droit contenant la classe ancêtre :
TMyClass = classe (TObject)
Les indicateurs de plage se trouvent à deux espaces de la marge et apparaissent dans l'ordre suivant :
TMaClasse = clss(TObject)
privé
protéger
publique
publié
fin;
Les données sont généralement déclarées uniquement dans la section privée, et leurs identifiants commencent par « F ». Toutes ces déclarations doivent être à 4 espaces de la marge :
TMyClass = classe (TObject)
privé
FMyDate : entier ;
fonction GetDate : Entier ;
procédure SetData (Valeur : Entier);
publique
publié
propriété MyData : entier lu GetData écrit SetData ;
fin ;
Les interfaces suivent les mêmes règles que leurs homologues, sauf que vous devez ignorer les indicateurs de portée et les données privées et utiliser le mot interface au lieu du mot classe.
convention de dénomination
À l'exception des mots réservés et des indicateurs, qui sont en minuscules, tous les identifiants Pascal doivent utiliser le format camelCase, c'est-à-dire que la première lettre de chaque identifiant doit être en majuscule, et la première lettre des mots intégrés doit également être en majuscule. cela ne prend que la première lettre.
MonIdentifiant
MaClasseFTP
La principale exception à cette règle concerne le cas des traductions de fichiers d'en-tête, qui doivent suivre les conventions de dénomination des fichiers d'en-tête d'origine. Par exemple:
WM_LBUTTONDOWN, n'écrivez pas wm_LButtonDown.
Sauf pour les traductions de fichiers d'en-tête, n'utilisez pas de traits de soulignement pour séparer les mots. Les noms de classe doivent être des noms ou des phrases nominales. Le nom de l'interface ou de la classe dépend de l'objectif évident et de l'utilisation de l'interface.
Réputation:
AddressForm, ArrayIndexOutOfBoundsException
Mauvais noms :
ManageLayout //Utiliser une expression verbale
delphi_is_new_to_me //Utiliser le soulignement
3.1 Dénomination des unités
Voir déclaration d'unité
3.2 Dénomination des classes/interfaces
Voir la déclaration de classe/interface
3.3 Dénomination de domaine/champ
Utilisez le format camelCase. Commencez par un « F » majuscule et déclarez toutes les données en privé, en utilisant des propriétés ou des getters et setters pour fournir un accès public. Par exemple : utilisez le nom GetSomething pour nommer une fonction qui renvoie une valeur de champ/champ interne, et utilisez SetSomething pour nommer une procédure qui définit une valeur de champ/champ.
N'utilisez pas toutes les lettres majuscules dans les sections const, sauf si cela est nécessaire pour la traduction du fichier d'en-tête.
Delphi a été développé en Californie, nous déconseillons donc l'utilisation de jetons, sauf si cela est nécessaire pour la traduction du fichier d'en-tête.
correct:
FMyString : chaîne ;
Incorrect:
lpstrMyString : chaîne ;
Bien entendu, la nomenclature hongroise est conservée dans la définition du type d'énumération :
TBitBtnKind = (bkCustom, bkOK, bkCancel, bkHelp,
bkOui, bkNon, bkFermer, bkAbort, bkRéessayer,
bkignore, bkAll);
Dans ce cas le caractère bk est inséré avant chaque élément de ce type énumération. bk signifie ButtonKind.
Lorsque vous envisagez les conventions de dénomination, évitez d'utiliser des noms à un seul caractère, à l'exception des variables à temps zéro et des variables de boucle.
Évitez d'utiliser la variable "l" (L), car elle est difficile à distinguer de "1" (un) sur une imprimante ou un moniteur.
3.4 Dénomination des méthodes
La dénomination des méthodes utilise également le format camelCase. Les conventions de dénomination des méthodes sont les mêmes que pour nommer les champs non const, mais elles peuvent être distinguées du contexte. La dénomination des méthodes doit imposer l’utilisation de verbes ou d’expressions verbales. Par exemple:
//Bon nommage de méthode :
ShowStatus, DrawCircle, AddLayoutComponent
// Mauvaise dénomination de la méthode :
MouseButton //expression nominale, pas de fonction de description
drawCircle // Commencer par une lettre minuscule
add_layout_component //Le soulignement est utilisé
//Les fonctions des méthodes suivantes ne sont pas assez claires. Est-ce qu'il démarre l'exécution d'un service (mieux : StartServer) ou détermine si un service est en cours d'exécution (mieux : IsServerRunning) ?
ServerRunning //Phrase verbale, mais pas une commande
Une méthode permettant d'obtenir ou de définir certaines propriétés de classe doit être appelée respectivement GetProperty ou SetProperty, où Property représente le nom de la propriété. Par exemple:
ObtenirHauteur, DéfinirHauteur
Une méthode qui teste une propriété booléenne d'une classe doit être nommée IsVisible, où Visible représente le nom de la propriété. Par exemple:
EstRedimensionnable, EstVisible
3.5 Nommer les variables locales
Les règles de dénomination des variables locales sont les mêmes que celles des champs/champs, sauf que "F" n'est pas utilisé. Voir la section 3.3.
3.6 Mots réservés
Les mots réservés et les indicateurs doivent être en minuscules. Cela peut parfois être un peu déroutant. Par exemple : Integer est un identifiant et apparaît avec la première lettre en majuscule. Les mots réservés dans la chaîne sont tous en minuscules.
3.7 Déclaration de type
Toutes les déclarations de noms de types commencent par la lettre T et suivent le même nom que la classe.
4.0 Utilisation de l'espace blanc
4.1 Lignes vides
Les lignes vides peuvent améliorer la lisibilité en regroupant des segments de code logiquement liés. Une ligne vierge peut également être utilisée aux endroits suivants :
Après le bloc de commentaires de copyright, la déclaration du package (package) et la section d'importation (import).
entre les déclarations de classe.
entre les déclarations de méthode.
4.2 Espaces
Object Pascal est un langage très clair et lisible. Habituellement, vous n'avez pas besoin d'ajouter beaucoup d'espaces pour séparer les lignes dans votre code. Les articles suivants fournissent quelques directives sur l'utilisation des espaces :
4.2.2 Les espaces ne doivent pas être utilisés :
Entre le nom de la méthode et le crochet ouvrant ;
Avant ou après l'opérateur .(point) ;
entre un opérateur unaire et son opérande ;
Entre un type et l'expression qu'il véhicule ;
après la parenthèse gauche et avant la parenthèse droite ;
après le crochet gauche et avant le crochet droit ;
avant une interdiction ;
Par exemple:
//Utilisation correcte :
function TMyClass.MyFunc(var Value: Integer);
MonPointeur := @MonEnregistrement;
MaClasse := TMaClasse(MonPointeur);
MonEntier := MonIntegerArray[5];
//Utilisation incorrecte :
function TMyClass.MyFunc( var Value: Integer );
MonPointeur := @MonEnregistrement;
MaClasse := TMaClasse ( MonPointeur ) ;
MonInteger := MonIntegerArray [ 5 ] ;
4.3 Retrait
Vous devez toujours mettre en retrait tous les niveaux de retrait de deux espaces. Autrement dit, le premier niveau est en retrait de deux espaces, le deuxième niveau est en retrait de quatre espaces, le troisième niveau est en retrait de six espaces... N'utilisez pas le caractère de tabulation Tab.
Bien entendu, il existe encore quelques exceptions. Les mots réservés comme unité, usages, type, interface, implémentation, initialisation et finalisation sont toujours en majuscules. Le dernier identifiant de fin de la cellule est également de niveau supérieur. Dans le fichier du projet, le programme ainsi que le début et la fin principaux se trouvent également dans la grille supérieure. Le bloc principal de début..de fin doit être mis en retrait d'au moins deux espaces.
4.4 Suite
Les lignes doivent être limitées à 80 colonnes. Les lignes comportant plus de 80 colonnes doivent être divisées en plusieurs lignes consécutives. Toutes les lignes suivantes doivent suivre la première ligne de cette déclaration et être indentées de deux caractères d'espace.
Par exemple:
//correct:
fonction CreateWindowEx(dwExStyle: DWord;
lpClassName : PChar ; lpWindowName : PChar ;
dwStyle : DWORD ; X, Y, nLargeur, nHauteur : Entier ;
hWndParent : HWND ; hMenu : HMENU ; hInstance : HINST ;
lpParam : Pointeur) : HWND ;
si ((X = Y) ou (Y = X) ou
(Z = P) ou (F = J) alors
commencer
S :=J;
fin ;
N'enroulez pas les lignes entre un paramètre et son type à moins que la liste ne soit séparée par des virgules, auquel cas placez-la avant le dernier paramètre afin que le nom du type commence sur la ligne suivante. Il ne doit y avoir aucun espace entre les deux points et sa variable, et il ne doit y avoir qu'un espace entre les deux points et le nom du type.
//correct:
procédure Foo(Param1 : entier ; Param2 : entier);
//erreur:
procédure Foo( Param :Integer; Param2:Integer);
Une ligne suivante ne doit pas commencer par un opérateur binaire. Évitez de couper une ligne là où les espaces n'apparaissent normalement pas, comme entre un nom de méthode et son crochet ouvrant, ou entre un nom de tableau et son crochet ouvrant. Si vous devez couper des lignes dans la situation ci-dessus, coupez la ligne après le crochet ouvrant ou le crochet ouvrant. Ne mettez pas start sur la même ligne que l'autre code.
Par exemple:
//erreur:
while (LongExpression1 ou LongExpression2 ) commence
//Faire quelque chose
//Faire quelque chose d'autre ;
fin ;
//correct
while (LongExpression1 ou longExpression2) faire
commencer
//Faire quelque chose
//Faire quelque chose d'autre ;
fin ;
si (LongExpressiong1) ou
(LongExpression2) ou
(ExpressionLongue3) alors
5.0 Commentaires
Le langage Pascal Objet prend en charge deux types de commentaires : les commentaires en bloc et les commentaires sur une seule ligne. Voici quelques directives d'utilisation des annotations :
·Il est utile de placer des commentaires en haut de l'unité expliquant le but de l'unité.
·Il est utile de placer des commentaires avant les déclarations de classe
·Il est utile de définir des annotations avant les déclarations de méthode
·Évitez les commentaires ayant des significations évidentes
i := i + 1; //Ajouter un à i
·N'oubliez pas que les commentaires facilement mal interprétés sont plus nuisibles que l'absence de commentaires du tout.
·Évitez de mettre des informations dans des commentaires qui semblent invalides
·Évitez d'insérer des astérisques ou d'autres symboles typographiques dans les bordures des commentaires
·Les commentaires zéro heure, c'est-à-dire les commentaires qui doivent être modifiés ou supprimés, doivent être marqués d'un « ??? : » devant eux, afin qu'ils soient faciles à trouver. Conceptuellement, tous les commentaires à temps zéro doivent être supprimés avant la sortie du programme.
// ??? : Modifiez ceci pour appeler Sort lorsqu'il est corrigé
Liste.MonSort ;
5.1 Bloquer les commentaires
Object Pascal prend en charge deux types de commentaires de bloc. Les plus couramment utilisés sont les commentaires entourés d’accolades {}. L'équipe Delphi a gardé les commentaires aussi peu nombreux et simples que possible. Par exemple : vous devez éviter d'utiliser des astérisques pour créer des motifs ou des lignes dans vos commentaires. Utilisez plutôt des espaces pour séparer vos commentaires, comme vous le feriez dans un document de traitement de texte. Les mots de votre commentaire doivent commencer sur la même ligne que la première accolade, comme dans l'extrait suivant de DsgnIntf.pas :
{ TPropertyEditor
Modifie une propriété d'un composant, ou une liste de composants,
sélectionné dans l'inspecteur d'objets.
L'éditeur est créé en fonction du type de
propriété en cours de modification selon les types
enregistré par...
etc...
ObtenirXxxValue
Obtient la valeur de la première propriété du
Propriété Properties. Appelle la propriété appropriée.
Méthode TProperty GetXxxValue pour récupérer le
valeur.
SetXxxValue Définit la valeur de toutes les propriétés
dans la propriété Propriétés Appelle le approprié.
Méthodes TProperty SetXxxxValue pour définir la valeur }.
Les commentaires en bloc sont souvent utilisés dans les commentaires sur les droits d'auteur. Également utilisé pour commenter certaines lignes de code.
Un commentaire de bloc expliquant le but de la méthode doit être précédé de la déclaration de la méthode.
Par exemple:
// CORRECT
{ TMonObjet.MaMéthode
Cette routine vous permet d'exécuter du code.
procédure TMyObject.MyMethod;
commencer
fin;
// INCORRECT
procédure TMyObject.MyMethod;
{************************************************* * ****
TMyObject.MyMethod
Cette routine vous permet d'exécuter du code.
************************************************** * *****}
commencer
fin;
Le deuxième type de commentaire en bloc contient deux caractères, des parenthèses et un astérisque : (* *). C'est ce qu'on appelle parfois un commentaire en forme d'étoile. Ces annotations ne sont généralement utiles que lors du développement du code, et leur principal avantage est qu'elles permettent aux annotations imbriquées d'avoir une profondeur inférieure à deux niveaux. Object Pascal ne prend pas en charge le même type d'imbrication de commentaires, il n'y a donc en réalité qu'un seul niveau d'imbrication : des accolades entre accolades en étoile, ou des accolades en étoile dans des accolades. Les annotations Pascal standard d'autres types dans les annotations de ce type seront ignorées tant que vous ne les imbriquerez pas. Par conséquent, vous pouvez utiliser cette syntaxe pour commenter un gros bloc de code contenant à la fois du code et des commentaires :
(* procédure TForm1.Button1Click(Expéditeur : TObject) ;
commencer
DoThis; // Démarrer le processus
DoThat; // Continuer l'itération
{ Nous avons besoin d'un moyen de signaler les erreurs ici, peut-être en utilisant
un essai enfin bloquer ??? }
CallMoreCode ; // Finaliser le processus
fin ; *)
Dans ce cas, l’intégralité de la méthode Button1Click est commentée, y compris tous les sous-commentaires qu’elle contient.
5.2 Commentaires sur une seule ligne
Un commentaire sur une seule ligne se compose d'un caractère de commentaire // et de son texte de début, avec un espace entre le texte et le caractère de commentaire. Si les commentaires sur une seule ligne se trouvent sur des lignes différentes de celles du code, ils doivent avoir le même niveau d'indentation que le code. Vous pouvez utiliser plusieurs commentaires sur une seule ligne pour former un commentaire volumineux.
Une ligne vide est obligatoire avant un commentaire sur une seule ligne ou un groupe de commentaires, sauf s'il s'agit de la première ligne d'un bloc. Si les commentaires sont utilisés pour plusieurs instructions, les commentaires et les groupes de commentaires doivent être suivis d'une ligne vierge. Si le commentaire explique uniquement l’énoncé de la ligne qui le suit, il n’est pas nécessaire qu’il soit suivi d’une ligne vide.
Par exemple:
// Ouvrir la base de données
Tableau1.Ouvert ;
Les commentaires sur une seule ligne peuvent également suivre les déclarations de code qu'ils expliquent. De tels commentaires sont parfois appelés commentaires de suivi. Il doit y avoir au moins un espace entre eux et le code. Si plusieurs commentaires de trace apparaissent simultanément dans un bloc de code, ces commentaires doivent être alignés.
Par exemple:
si ( pas IsVisible) alors
Quitter ; // rien à faire
Inc(StrLength); // réserver de l'espace pour le terminateur nul
Évitez de tracer des commentaires sur chaque ligne de code exécutable. Il est généralement préférable de limiter l'utilisation des commentaires, voire de les laisser vides, entre les blocs start..end d'une méthode ou d'une fonction. Des commentaires longs peuvent apparaître dans des commentaires en bloc avant la définition des méthodes et des fonctions.
gentil
6.1 Organisation des cours
L’organisation des instances de classe doit suivre l’ordre suivant :
·Déclaration de domaine/champ
·Déclaration de méthode
·Définition d'attribut
Les domaines/champs, propriétés et méthodes doivent être indexés par ordre alphabétique de leurs noms.
6.1.1 Niveaux d'accès
À l'exception du code généré par l'EDI, les indicateurs de portée des classes doivent être dans l'ordre suivant :
·déclaration privée
·déclaration de protection
·déclaration publique
·Déclaration publiée
Dans Object Pascal, les membres de la classe disposent de quatre niveaux d'accès : publié, public, protégé et privé, par ordre décroissant de capacités d'accès. Le niveau d'accès par défaut est publié. En règle générale, un membre doit se voir attribuer le niveau d'accès le plus bas qui lui convient le mieux. Par exemple : les membres auxquels seules les autres classes de la même unité peuvent accéder doivent être déclarés privés. Dans le même temps, déclarer des membres avec de faibles niveaux d’accès donne également au compilateur la possibilité d’améliorer l’optimisation. Bien entendu, d’un autre côté, l’utilisation de faibles niveaux d’accès rend difficile l’extension des sous-classes. S'il y a des raisons de croire qu'une classe sera sous-classée à un moment donné dans le futur, alors les membres qui doivent être hérités et étendus par la sous-classe doivent être déclarés comme protégés. Les propriétés utilisées pour accéder aux données privées peuvent également fournir cette protection.
Vous devez interdire l’accès public aux données. Les données sont généralement déclarées dans la section privée et tout accès public à celles-ci doit se faire via les méthodes ou propriétés GetXXX, SetXXX.
6.1.8 Déclaration du constructeur
Les méthodes doivent être triées par index alphabétique. Il est correct de placer les constructeurs et les destructeurs au début de la section publique ou de les classer par ordre alphabétique.
S'il existe plusieurs constructeurs ou si vous utilisez plusieurs constructeurs portant le même nom, ils doivent être disposés en fonction de la liste des paramètres, celui avec le moins de paramètres devant celui avec le plus de paramètres. Cela signifie que s'il existe un constructeur sans paramètres, il doit apparaître en premier. Afin de conserver la meilleure compatibilité avec C++Builder, la liste des paramètres du constructeur doit être unique. C++ n'appelle pas un constructeur en fonction de son nom, donc la seule façon de distinguer plusieurs constructeurs consiste à utiliser sa liste d'arguments.
6.2 Déclaration de méthode
Si possible, les déclarations de méthode doivent apparaître sur une seule ligne.
Par exemple:
Exemples :
procédure ImageUpdate (Image img, infoflags : Integer,
x : Entier, y : Entier, w : Entier, h : Entier)
Interface 7.0
Une déclaration d'interface a la même forme qu'une déclaration de classe :
InterfaceName = interface ([ Interface héritée ])
InterfaceCorps
fin ;
Les déclarations d'interface doivent être indentées de deux espaces, les corps d'interface de quatre espaces et les caractères de fin de deux espaces.
Il n'y a pas de champs/champs dans la déclaration d'interface. Mais des attributs peuvent apparaître.
Toutes les méthodes d'interface sont intrinsèquement publiques et abstraites, et il n'est pas nécessaire d'inclure de tels mots-clés dans la déclaration d'interface.
Sauf indication contraire, les déclarations d'interface ont le même style que les déclarations du même type.
7.1 Organisation de l'organisme d'interface
Le corps de l'interface peut être organisé dans l'ordre suivant :
·Déclaration de méthode d'interface
·Déclaration d'attribut d'interface
Les méthodes et propriétés d’interface sont déclarées dans le même style que les classes.
8.0 Déclaration
Une instruction est une ou plusieurs lignes de code se terminant par un sceau. Une instruction unique n'a qu'un seul numéro d'interdiction et une instruction composée a plusieurs noms d'interdiction.
//Il s'agit d'une seule instruction :
UNE := B;
//Il s'agit d'une instruction composée :
commencer
B :=C;
UNE := B;
fin ;
8.0.1 Déclaration unique
Si une seule instruction doit être enveloppée, elle doit être indentée de deux espaces par rapport à la ligne précédente.
//Par exemple:
MaValeur :=
MaValeur + (SomeVeryLongStatement / OtherLongStatement);
8.1.1 Déclarations d'affectation et d'expression
Il ne peut y avoir qu'une seule instruction par ligne.
Par exemple:
a := b + c; Inc(Compte); //Erreur
a := b + c; //Corriger
Inc(Compte); //Corriger
8.1.2 Déclaration des variables locales
Les variables locales utilisent également le format camelCase. N'utilisez pas le leader "F", qui est réservé aux champs/champs dans les déclarations de classe.
Par exemple:
var
MesDonnées : Entier ;
MaChaîne : chaîne ;
Vous pouvez déclarer plusieurs variables du même type sur la même ligne :
var
ArraySize, ArrayCount : entier ;
Cette habitude de déclaration n'est pas recommandée dans les déclarations de classe.
8.1.3 Déclaration de tableau
Il est courant de toujours mettre un espace avant la parenthèse ouvrante et après la parenthèse fermante :
taper
TMyArray = tableau [0..100] de Char ;
8.2.3 instruction if
L'instruction if doit apparaître sur au moins deux lignes :
Par exemple:
//erreur:
si A = B alors DoSomething ;
//correct
si A = B alors
Faire quelque chose ;
S'il s'agit d'une instruction if composée, il devrait y avoir une nouvelle ligne pour chaque délimiteur :
//erreur:
si A = B alors commencez
Faire quelque chose ;
Faire autre chose ;
fin sinon commence
Faites ceci ;
Faites cela ;
fin ;
//correct
si A = B alors
commencer
Faire quelque chose ;
Faire autre chose ;
fin
autre
commencer
Faites ceci ;
Faites cela ;
fin ;
Quelques variantes des éléments suivants peuvent être adoptées :
//correct
si Condition alors
commencer
Faites ceci ;
fin sinon
commencer
Faites cela ;
fin ;
//correct
si Condition alors
commencer
Faites ceci ;
fin
autre
Faire quelque chose ;
//correct
si Condition alors
commencer
Faites ceci ;
fin sinon
Faire quelque chose ;
//La méthode suivante n'est peut-être pas prise en compte, mais elle mérite des éloges :
si Condition alors
Faire ceci
sinon fais ça;
8.2.4 pour la déclaration
Exemple:
// INCORRECT
pour i : = 0 à 10 commence
Faire quelque chose ;
Faire autre chose ;
fin ;
// CORRECT
pour i := 0 à 10 fais
commencer
Faire quelque chose ;
Faire autre chose ;
fin ;
8.2.5 instruction while
Exemple:
// INCORRECT
tandis que x & lt ;
Faire quelque chose ;
Faire autre chose ;
fin ;
// CORRECT
tandis que x & lt ;
commencer
Faire quelque chose ;
Faire autre chose ;
fin ;
8.2.6 répéter jusqu'à l'instruction
Exemple:
// CORRECT
répéter
x := j;
j := UpdateValue;
jusqu'à j = 25 ;
8.2.7 déclaration de cas
Exemple:
// CORRECT
cas Contrôle.Alignement de
alLeft, alNone : NewRange := Max(NewRange, Position);
alRight : Inc(AlignMargin, Control.Width);
fin ;
// CORRECT
cas x de
CSSDémarrer :
commencer
j := UpdateValue;
fin ;
csDébut : x := j;
csTimeOut :
commencer
j :=x;
x := UpdateValue ;
fin ;
fin ;
// CORRECT
cas ScrollCode de
SB_LINEUP, SB_LINEDOWN :
commencer
Incr := FIncrement div FLineDiv;
FinalIncr := FIncrement mod FLineDiv;
Compte := FLineDiv ;
fin ;
SB_PAGEUP, SB_PAGEDOWN :
commencer
Incr := FPageIncrément;
FinalIncr := Incr mod FPageDiv;
Incr := Incr div FPageDiv;
Compte := FPageDiv ;
fin ;
autre
Compte := 0 ;
Augmentation := 0;
FinalIncr := 0;
fin ;
8.2.8 instruction try
//Correct
essayer
essayer
EnumThreadWindows (CurrentThreadID, @Disable, 0);
Résultat := TaskWindowList ;
sauf
ActiverTaskWindows(TaskWindowList);
augmenter ;
fin ;
enfin
TaskWindowList := SaveWindowList;
TaskActiveWindow := SaveActiveWindow;
fin ;
Blog de l'auteur : http://blog.csdn.net/sailerbai/