begin process at 2012 02 11 15:15:59
  Trouver un code source :
 
dans
 
Accueil > 

Tutoriels

 > 

Tutoriaux

 > [DELPHI] CONVENTIONS D'ÉCRITURE DES IDENTIFIANTS DE VARIABLES ET METHODES

[DELPHI] CONVENTIONS D'ÉCRITURE DES IDENTIFIANTS DE VARIABLES ET METHODES


 Information sur le tutoriel

Note :
8,67 / 10 - par 3 personnes
8,67 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10

 Description

Bonjour, comme le savent ou ne le savent pas, il existe des conventions d'écriture des identifiants dans Delphi.
Ces conventions permettent d'identifier d'une manière standard et normaliser des nom de variables ou de méthodes dans Delphi afin que tout les développeurs s'y retrouves même si il ne s'agit pas de leurs codes sources.

Ce tutoriel est plutôt destiné aux débutants qui souhaitent acquérir une certaine maitrise du code en général et a ceux qui souhaite améliorer l'écriture de leurs codes pour mieux les partager.

Tutorial

Conventions générales :

    Les identifiants doivent toujours êtres écris en Anglais et s'approcher le plus possible d'un code écrit par un professionnel. Utilisez l'outil de traduction de Google ou un dictionnaire d'anglais pour traduire vos identifiants. Pensez toujours à le faire, car même si vos codes sont destinés à un public francophone, il se peut que des personnes étrangères s'y intéressent et les utilisent.

    Evitez d'une manière générale les identifiants à rallonge ou encore trop court ou abstrait. L'identifiant doit permettre d'identifier clairement une variable ou un type, son utilisation, son but, son origine etc.

    En pascal Objet, les identifiant sont écrit la plupart du temps en se qu'on appel "le dos de chameau" car chaque mots commence par une majuscule et la suite en minuscule, ce qui provoque des "bosses" dans leurs noms.
Exemple :
    TListBox, TComboBox, FontSizeAera.


    Les noms écrits avec une convention C,C++ (majuscule et underscore) sont réservé la plupart du temps aux types paramètres, aux méthodes écrites en assembleur, aux types devant d'abord être redéclarer ou suite à une traduction 1:1 d'un header C,C++.
Exemple :
    WM_MOUSE_LEFT, VK_ESCAPE, function _DIV


    Les conventions données ci-dessous, sont tirées directement ou établies à partir des codes émis par Borland et également les plus souvent rencontrées.
Notez bien que ces conventions sont uniquement faites pour harmoniser les écritures de codes entre développeurs permettant ainsi une meilleure compréhension entre tous et facilitant le travail en équipe.
Avec le développement d'Internet, il n'est plus rare de voir travailler ensemble des développeurs indépendants issus de différentes nations, il est donc nécessaire de respecter certaines normes.
    

    Bien sur, elles restent facultatives, mais n'oubliez pas qu'elles ajouteront en qualités de finitions à vos codes, ce qui n'est pas négligeable.



A) Dénominateurs communs des identifiants :

    Les dénominateurs communs peuvent être placés a l'intérieur du nom d'un identifiant ou comme suffixe la plupart du temps.


    Servez vous de cette liste comme memo pour écrire vos identifiants, cette dernière n'en représente que quelques-uns ... ils en existent d'autre mais les citer tous serait trop long.

    Ancien        : [O, Old]
    Buffer        : [Bf, Buf,Buffer]
    Booléen         : [Bl, Bool]
    Bouton        : [Bt, Btn,Button]
    Caractère         : [C, Ch, Chr]
    Carré            : [Sq, Sqr, Square]
    Chaine        : [S, Str]
    Cellule        : [Cell]
    Charger        : [Load]
    Colonne        : [Cl, Col]
    Compteur        : [Cn, Cnt, Count]
    Coordonnées        : [X, Y, Z, L, R, Left, Right, Top, Bottom]
    Couleur         : [Cl, Col, Color]
    Curseur         : [Cr, Cur]
    Dialogue        : [Dlg, Dialog]
    Dimensions        : [W, Wh, Width, H, Ht, Height]
    Donnée        : [Dt, Dat, Data]
    Double        : [Dbl]
    Enregistrement    : [Rc, Rec]
    Ensemble        : [Set]
    Entier        : [I, Int]
    Etendus         : [E, Ext]
    Flottant        : [F, Flt, Float]
    Générateur        : [Gn, Gen, Generator]
    Image         : [Img, Gfx, Pic]
    Information     : [Nfo, Inf, Info]
    Langage         : [Ln, Lng, Lang, Language]
    Ligne         : [Rw, Row, Ln, Line]
    Localisation    : [Loc, Locate]
    Maximum         : [M, Mx, Max]
    Message         : [Msg, Messy, Message]
    Minimum         : [N, Mn, Min]
    Objet         : [O, Ob, Obj, Object]
    Paramètre         : [Prm, Param, Parameter]
    Pixel         : [Px, Pix, Pixel]
    Point         : [Pt, Pnt, Point]
    Pointeur        : [P, Ptr]
    Position        : [Ps, Pos]
    Prime, Primaire    : [Pm, Prim]
    Rectangle         : [Rt, Rct, Rect]
    Registre        : [Rg, Reg, Registry]
    Ressource         : [Rc, Res, Resource]
    Sauver        : [Sv, Save]
    Son             : [Sn, Snd, Sound]
    Système         : [Sys, System]
    Tableau         : [A, Ar, Arr, Array, Mtx, Matrix]
    Texte         : [Tx, Txt, Text]


B) Résumé des conventions des identifiants de types :

    Tout types        : [T]Nom

    ensemble        : [T]Nom[s (au pluriel)]
    événement        : [T]Nom[Event]
    exception        : [E]Nom[Error]
    fonction        : [T]Nom[Func]
    interface        : [I]Nom[Interface]
    message        : [T]Nom[Message]
    objet            : [T]Nom[Obj (facultatif)]
    paramètre        : NOM_TYPE ou Nom[Param, Parameter]
    pointeur        : [p, P]Nom
    procédure        : [T]Nom[Proc]
    record        : [T]Nom[Rec (facultatif)]
    tableau dynamique    : [T]Nom[DynArray (facultatif)]
    tableau statique    : [T]Nom[Tri, Quad][Array, Matrix, Vector]


C) Résumé des conventions des identifiants de variables :

    argument de méthode        : [A]Nom
    autre variable            : Nom[Dénominateurs communs]
    constante                : [C, Cs]Nom
    variable privée de classe    : [f]Nom

    
D) Résumé des conventions des identifiants de méthodes :

    appel d'événement        : [Do]Nom
    conversion            : NomTypeA[To]NomTypeB
    création, constructeur    : [Create]
    détruire, destructeur    : [Destroy]
    définition de valeur    : [Set]Nom
    dessin quelconque        : [Draw,Paint]Nom
    effacer, vider        : [Clear, Erase, Delete]Nom
    événement            : [On]Nom
    initialiser            : [Init, Initialize]Nom
    libérer            : [Free]Nom
    message            : [CM, WM, Msg]Nom
    mettre a jours        : [Upd, Update]Nom
    retour de valeur        : [Get]Nom
    réinitialiser        : [Reset]Nom
    vérification d'état    : [Is]Nom


E) Conventions Delphi et C++, comparaison :
    
    Entre le Delphi et le C++ il existe une grosse différence pour écrire les identifiants. En Delphi on écrira toujours les identifiants en commençant par une majuscule chaque mot qui compose ce dernier.

Exemple :

    TMonTypeAMoi

    ProcedureQuiConvertisLesBitmapEnJPEG



En C++ on écrira plutôt les identifiants en majuscule avec un caractère Underscore (Shift+8) entre chaque mot qui le compose.

Exemple :

    MON_TYPE_A_MOI


    On peu bien sur utiliser l'une ou l'autre, voir les mélangées, le compilateur lui ne fait pas attention aux conventions d'écriture (mais il vérifie la syntaxe quand même ^^).
En Delphi, la convention d'écriture C++ est généralement utilisée pour les paramètres ou les valeurs constantes.

Exemple :
    Type
        TParamSound = $00..$7F;


    Const

        // Ecriture type C
        PRM_SOUND_OFF    : TParamSound = $00;
        PRM_SOUND_ON    : TParamSound = $01;
        PRM_SOUND_MIX    : TParamSound = $02;


        // Ecriture type Delphi
        PrmSoundOff        = PRM_SOUND_OFF;
        PrmSoundOn        = PRM_SOUND_ON;
        PrmSoundMix        = PRM_SOUND_MIX;



F) Rappel d'écriture global des identifiants :
    
    Pour n'importe quel identifiant, qu'il s'agisse d'une procédure, d'un type, d'un composant etc. Gardez une chose a l'esprit, c'est que l'identifiant doit permettre l'identification du type et/ou de l'utilité de l'élément qu'il nome.

Il ne doit n'y être trop court, ni trop long et ne doit en aucun cas avoir le même nom qu'un autre élément accessible dans l'unité en cours ou une autre.

Vous constaterez par vous même la jolie erreur des développeurs de Borland qui ont laissé le nom RECT a un argument dans l'événement OnDrawItem du composant TListBox... Ce nom d'argument écrase directement la fonction RECT() de l'unité Classes ce qui empêche l'utilisation de cette dernière dans cet événement et pourtant tout le monde sait a quel point cette fonction est utilisée pour les dessins dans les canvas.

Ce genre d'erreur force le développeur a "forcer" le nom de l'unité qui contient la fonction et donc il doit ajouter Classes.Rect() pour éviter les confusions du compilateur.

Au-delà de ces conventions d'écriture, vous pouvez (et devriez systématiquement) ajouter des commentaires court et explicite au dessus ou à coté des déclarations pour expliquer plus en détails le rôle d'un élément de code, l'intervalle min..max d'une valeur, les restrictions, etc.


F.1) Les types en général :

    L'écriture d'un nom de type commenceras toujours par la lettre majuscule "T" (pour type).
Cette convention s'applique sur tout les types a l'exception du type Interface qui lui commenceras par la lettre majuscule "I" (pour interface).

Pour un type Interface, on commencera non seulement par la lettre "I" mais on ajoutera également à la fin la dénomination "Interface".

Pour un type pointeur, on ajoutera la lettre minuscule ou majuscule "p" ou "P" (pour pointeur).
        
Exemple :
    TColor = $F7FFFFFF..$FFFFFFFF;
    TComboBox = class;

    IOLEInterface = interface;
    IHTTPInterface = interface;

    pColor = ^TColor;
    pPoint = ^TPoint;


F.2) Les types énumérés, ensembles et tableaux :

    L'ajout de certaines dénominations dans le nom du type ou de la variable peut être utile pour la différencier d'un type dérivé ou quasi identique, par exemple pour les types "Set of" la plupart du temps on mettra au pluriels le type Set of [type]. Pour les types tableaux "array of" on ajouteras la lettre majuscule "A" après le "T" majuscule ou aussi le préfixe "Arr" ou encore le suffixe "Array" après le nom du type.
    
Pour les types tableaux, l'ajout de dénominateur tel "vector", "matrix", "tri", "quad" permettent de définir encore plus le type.
La dénomination "Dyn" (pour dynamique) permet de faire la différence entre un tableau statique (array[0..n] of) et un tableau dynamique (array of)
    
Pour les type énumérés, les identificateurs de valeurs commencerons généralement par deux lettres significative en minuscule, elles correspondent la plupart du temps aux "initiales" du nom du type.
    
Exemple :
    TFontStyle    = (fsBold, fsItalic, fsUnderstrike);
    TFontStyles = set of TFontStyle;
        
    TTextAlignment = (taLeft, taCenter, taRight);
        
    TFontStylesDynArray = array of TFontStyles;
        
    TIntegerDynQuadArray = array of array[0..3] of integer;


F.3) Les types méthodes :

    Pour les types Procédure ou Fonction, on ajouteras non seulement la lettre majuscule "T" au début du nom, mais également le suffixe "Proc" ou "Func" a la fin du nom de l'identifiant, "Event" si il s'agit d'un événement, Message si il s'agit d'un message.
    
Exemple :
    TNotifyEvent = procedure(Sender: TObject) of object;
    TTimeEvent = procedure(Sender: TObject; ATime : TTime) of object;
        
    TIntegerProc = procedure(Value: Integer);
    TFloatProc = procedure(Value: Extended);
        
    TIntegerFunc = function(Value: Integer): Integer;
    TFloatFunc = function(Value: Extended): Extended;

        
F.4) Les variables :

    Les variables n'ont pas réellement de conventions, sauf a l'identique des types ensembles ou tableaux, l'ajout de dénominateurs permettant d'identifier leurs type d'origine.
    
Les deux seules vraies conventions pour les variables s'applique seulement sur Les arguments de méthodes, ou le nom des identifiants devrait toujours commencer par la lettre "A".

Exemple :
    function RectWidth(ARect: TRect): integer;

Et les variables déclarées en zone private dans une classe, qui doivent commencer par la lettre "F".

Exemple :
    TTestClasse = class
    private
        fInt : Integer;
        fFlt : Extended;
    end;

    
F.5) Les constantes :

    Les constantes sont régies par les mêmes conventions que les variables.
Vous pouvez, pour les différencier des variables, ajouter une lettre majuscule "C" devant le nom de l'identifiant ou encore, comme nous le rappel si bien Florenth (et d'ailleurs je vois et fais souvent cela aussi) écrire la constante avec une convention C++ soit en majuscule avec underscore entre chaque mots.

Exemple :
    Const
        CDegRad = 180/Pi;
        DEG_RAD = 180/Pi;

    
F.6) Les méthodes, procédures et fonctions :

    Les méthodes doivent elles aussi avoir un nom qui définit correctement leurs utilisation.
La plupart du temps un nom simple comme Draw, Paint, Refresh permet de tout de suite savoir a quoi elles servent.
    
Il existe néanmoins des conventions spéciales pour certaines méthodes :

  • Les méthodes d'appels d'événements dans une classe commenceront généralement par "Do". (DoTextChange)
  • Les méthodes événements commenceront en général par "On". (OnTextChange)
  • Les messages commenceront en général par "CM" ou "WM". (CMTextChange)
  • Les méthodes servant à définir une valeur commenceront par "Set" (SetText)
  • Les méthodes servant à renvoyer une valeur commenceront par "Get" (GetText)
  • Les méthodes servant à connaitre un état particulier commenceront par "Is" (IsTextEmpty)
  • Les méthodes de conversions A vers B devront contenir le nom des deux type séparés par "To" (TextToUnicode)

 Historique

18 avril 2006 23:38:12 :
petits rajouts...
06 mai 2006 05:37:56 :
petite correction de la mise en page ...
07 mai 2009 21:07:37 :
présentation et correction
10 mai 2009 14:04:42 :
DOCX = GROS CACA QUI PUS!

Commentaires

Commentaire de f0xi le 18/04/2006 08:48:35 administrateur CS

Voila, c'est le premier jet de ce tuto que je cherche a ecrire depuis un moment.
j'attend vos commentaires et si vous remarquez des erreur ou des possibilitées d'ajout faites le moi savoir.

Commentaire de florenth le 18/04/2006 19:25:31

f0xi, ou comment écrire du code propre et élégant.
Bravo pour ce tuto, il interessera surement plus sun de ce site.

Personnellement, je suis à la règle toutes ces recommendations depuis un sacré bout de temps.
Mais il manque une élément important: le nommage des composants !!
Je sais, ça ne fait pas entièrement parti de ton tuto, mais c'est tellement utile de le préciser.

Alors je complète:
"7) Le nommage des composants

En principe, et c'est logique, les noms des composants doivent spécifier concretement l'utilité du composant dans le programme. Le préfixe doit contenir (mais pas obligatoirement, il y a des exeptions) une forme abrégée de la classe du composant.

Exemples:
miQuitter est le TMenuItem qui permet de qutter le programme.
BtnActualiser, je vous laisse deviner.
memoRapport, là aussi.

Il y a plusieurs variantes de ce côté là. Certains écrivent la première lettre en majuscule, d'autres en minuscule pour la distinguer du réél nom du compo. Ma foi, on s'en fiche un peu, du moment que le préfixe est présent."

Bref, voila de quoi compléter ton ébauche, qui, malgré son nom, est plutot aboutie
Personnellement, je nomme mes constantes MA_CONSTANTE_QUI_CONTIENT_CA. C'est un choix personnel, mais ça permet de les différencier des variables.

Sur ce, a+

Commentaire de f0xi le 18/04/2006 23:40:15 administrateur CS

oui florenth, trés bonne remarque, de plus je le fais aussi de mettre les constantes en majuscules (parfois)...

j'ajoute donc cela.

Commentaire de Forman le 27/05/2006 12:03:13

Juste une remarque: j'ai l'habitude (et je ne suis pas le seul) de commencer mes variables singleton par G (comme Global) par exemple:

GMemoryManager

Et pour les constantes de message d'erreur elles commence en général par s minuscule:

sInvalidOp
sDivisionByZero

Commentaire de Debiars le 20/07/2006 15:34:28

Pas mal, foxi... et pourtant, une phrase me choque, la première :

"Les identifiants doivent toujours etres ecris en Anglais".

Quand je pense qu'on s'est battu dans les années 70 pour obtenir des constructeurs américains des brochures et des manuels en français.

Tu dis que des étrangers peuvent vouloir déchiffrer nos codes.
Ok (sic), ils feront comme nous quand nous allons sur un site anglais ou allemand, voir belge.

A part ça et l'orthographe, ça baigne...

Amicalement!  

Commentaire de WhiteHippo le 21/08/2007 13:30:26

Pour tous ceux qui veulent rentrer dans le moule et/ou qui sont intéressés par le sujet, la référence officielle Borland sur la standardisation du Pascal Objet se trouve à cette adresse :
http://dn.codegear.com/article/10280

Cordialement.

Commentaire de hfr11 le 26/10/2007 13:55:43

Bonjour à tous...
Je me réfèrerai simplement aux commentaires déjà présents pour ajouter ceci :
  On peut toujours mieux faire !
Alors pourquoi ne pas oser, pourquoi ne pas créer petit à petit NOTRE norme, bien Française, en s'appuyant sur l'existant en y ajoutant simplement les marques de nos origines et de notre logique expérimentale.
Désormais :
- J'adopte le G devant une variable GLOBALE (ex : GCheminApplication ou GPathExe pour le chemin de mon application)
- J'adopte le Cte devant une Constante      (ex : CteIndiceNomGrilleUtilisateurs pour l'indice de colonne du nom d'utilisateur dans ma grille, ça fait long, c'est vrai, CteIndNomGrUsr serait plus pratique...)
- J'adopte le Msg devant une variable Message
Si chacun s'y met, chacun critique et donne sa vue du problème, d'ici quelques mois, nous aurons notre norme, Française, et aussi compréhensible que la norme anglaise actuelle...
Tout ceci, bien sûr, n'engage que moi, tout au moins jusqu'à maintenant.
Tout n'est-il pas que question de point de vue ?
Je vous invite donc à délirer, le résultat peut en valoir la peine.
L'essentiel pourtant n'est-il pas que son code soit clair ?
"Chaque loi promulguée remplace un système de valeur, évite à chacun de juger des situations et de prendre une décision, c'est le meilleur moyen de fabriquer des VEAUX !"
J'accepte la différence, cordialement, Patrice

Commentaire de florenth le 26/10/2007 15:57:05

Justement... s'il y a bien un langage compréhensible par deux personnes vivant à 5000km l'une de l'autre, c'est l'anglais !
Alors, vouloir coder "français", c'est tourner le dos à tous les francophobes (je ne parle pas du général ^^), et je trouve cela dommage.

Et au lieu de fabriquer des veaux, je ferai un voeu: "développeurs de tous les pays, unissez-vous !"

Commentaire de monnet le 08/02/2009 18:28:25

Bon artiqule mé kel domaje qil y es plain de fots de fransai !

Ne serait-il pas possible de te relire avant de publier ton article ?

 Ajouter un commentaire




Nos sponsors


Sondage...

Comparez les prix

CalendriCode

Février 2012
LMMJVSD
  12345
6789101112
13141516171819
20212223242526
272829    

Consulter la suite du CalendriCode

Photothèque

 
Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils.
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés

Google Coop CodeS-SourceS Google Coop CodeS-SourceS
Temps d'éxécution de la page : 0,546 sec (4)

Nous contacter | Annoncer sur CodeS-SourceS | Mentions légales