[NAMING CONVENTION]-Convention de nommage

[flaith]

Hello tout le monde,

Qu'-est-ce donc ? (tiré de wikipédia) :
"Une convention de nommage dans la programmation informatique est un ensemble de règles destinées à choisir la séquence de caractères à utiliser pour les identifiants dans le code source et la documentation."

C'est ce que j'utilise depuis qq temps lors de la création de programmes professionnels et que j'utilise, de temps en temps, lorsque je programme pour le plaisir.

Je penses que cela peut devenir, pour les débutants, un bon début.

Ceci est la convention que je me suis créé, c'est un exemple, à partir de celle-ci vous pouvez créer la votre.

Code : Tout sélectionner

Naming Convention
-----------------
Version #5 du 13/11/2010
Nicolas Djurovic


•	On définit les variables en fonction de leur type (pour types: Global, Protected, Define, Static) :

SAUF si cela concerne des variables utilisées, par exemple, pour les boucles 'for' : i, j, k, ...


ex: 

   - type Byte      ==> bVariable
   - type Ascii     ==> aVariable
   - type Character ==> cVariable
   - type Word      ==> wVariable
   - type Unicode   ==> uVariable
   - type Long      ==> lVariable
   - type Integer   ==> iVariable
   - type Float     ==> fVariable
   - type Quad      ==> qVariable
   - type Double    ==> dVariable
   - type String    ==> sVariable


Cas particuliers:

   - type pointeur  ==> *Variable
   - type Structure ==> Variable

   Pas de définition car on a la Structure suivante:

      Structure CS_Structure     ; Ici on met 'CS_' + le 1er car du nom en majuscule
        sName.s
        sSurname.s
        iAge.i
        *Icone.ICONIMAGE         ; Cas spécial ou on utilise une structure système définie
      EndStructure


   Ensuite la définition d'une variable de type structure devient :

      Protected _Variable.CS_Structure
         ou
      Global Variable.CS_Structure
         ou
      Define.CS_Structure *Variable




•	Les variables paramètres des procédures doivent commencer par un double '_' + caractère du type

ex: Procedure InsertSQL(__iType_Pref.i, __iNb_Value.i)




•	Toutes les variables internes définies dans une procédure doivent commencer par '_'

ex: Protected.s _sName, _sSurname
ex: Protected.i _iAge




•	Les constantes seront définies de cette façon :

ex: 

     #CONST_INTEGER  = 3
     #CONST_FLOAT    = 3.1415
     #MAIN_Win_Width = 640
     #CONST_STRING   = "String"
       ou
     #CONST_STRING$  = "String"




• Les énumérations sont déclarées comme les constantes :

    Enumeration
       #MAIN_Win_ProgName
       #MAIN_Label_Title
       #MAIN_Frame_Sep_1
       #MAIN_Button_Ok
       #MAIN_Button_Cancel
     EndEnumeration




•	Les labels définis dans DataSection doivent être préfixés par '_DS_' sous la forme :

DataSection
  _DS_NameOfLabel:
    Data.s  "XXXXxxxxxxxx......."
    Data.s  ..............
    Data.i  99999
EndDataSection




•	EnableExplicit doit toujours être utilisé




•	Lors insertion de fichiers include, le plus possible utilisation de :

IncludePath #PB_Compiler_Home+"Includes"
  XIncludeFile "IncludeFile.pbi"
IncludePath ""




•	L'indentation doit être respectée pour une meilleur lisibilité

Tabulation : 2 espaces (ou 4 maximum)




•	Et, le plus important : METTRE LE MAXIMUM DE COMMENTAIRES

[Ar-S]

C'est effectivement un "Naming" qui peut s'avérer pratique.
C'est une bonne idée.

[Backup]

ton post aurai pu etre mis là
http://www.purebasic.fr/french/viewtopic.php?f=1&t=8982

ce que tu ecris est vrais , cependant , il suffit aussi d'utiliser le Type
tout simplement

au lieu d'ecrire "aVariable"
il suffit de laisser Variable$ partout
ou de laisser Variable.s partout ou l'on utilise cette variable !!


je suis d'accord avec le principe, souvent je tombe sur des codes, ou il me faut chercher a quoi correspond telle ou telle variable

deja que beaucoup ne mettent pas Next u
mais juste un laconique "Next"

et lorsque tu as des boucles imbriqué avec de long tests au millieu, si on se plante d'un Endif
et qu'on tombe sur ce Next tout seul, on sait plus s'il faut mettre le endif Avant ou apres
bref, perte de temps

[case]

oui enfin l'indentation ca aide pas mal pour les problèmes que tu cites

[flaith]

C'est vrai que l'indentation est nécessaire, voire primordiale.
Mais c'est surtout pour savoir à quoi correspond une variable quand on voit une partie d'un programme ou, et surtout, quand on travaille à plusieurs sur celui-ci
Concernant le type variable$, je ne l'utilise que pour pendant les phases de tests, j'l'aime pas trop ce type de variable