Le point sur les conventions de noms de variables

Réponses

• Bru Membre

  mars 2006 19:38 modifié #2

  Vaste débat...
  
  Les seules "conventions" que j'utilise :
  - les variables d'instance commencent par _
  - les variables de classe commencent par __ (2 underscores)
  - les constantes (#define) sont en majuscule
  
  J'ai aussi l'habitude de préfixer mes outlets par _IBO_ et les actions par _IBA_.
  
  Pour la position de * pour les pointeurs, je suis plutôt de la secte des coleurs d'étoile au nom de la variable ([tt]void *unPointeur).[/tt]
  
  Le reste, c'est plutôt au pif.
  
  .
• System

  mars 2006 19:38 modifié #3

  Pareil que bru, sauf que je ne différencie pas les outlets des autres variables (donc uniquement _) et pour les actions, je suffixe Action.
  
  Pour les array, dico et set, je me contente du s à  la fin.
  
  Complément: rattacher le symbole du pointeur à  la variable permet de rester cohérent si on déclare plusieurs variables d'un meme type sur une ligne (NSObject *obj1, *obj2;).
• Bru Membre

  mars 2006 19:38 modifié #4

  dans 1143191113:

  
  Complément: rattacher le symbole du pointeur à  la variable permet de rester cohérent si on déclare plusieurs variables d'un meme type sur une ligne (NSObject *obj1, *obj2;).
  

  
  
  Oui, surtout que l'étoile qualifie le nom de la variable, et non son type.
  
  Par exemple :
  char*  c1,  c2;
  Dans cette déclaration, c1 sera bien un pointeur sur un caractère, mais c2 sera un caracère !
  
  Donc c'est plus joli d'écrire :
  char  *c1,  c2;
  
  .
• muqaddar Administrateur

  mars 2006 19:38 modifié #5

  OK !
  Je suis d'accord avec vous.
  
  Question, ce que vous appelez variables de classe, c'est ce que j'ai appelé variable de méthode ?
• System

  mars 2006 19:38 modifié #6

  des variables déclarées avant le @implementation (les fameuses sharedInstance notamment).
• muqaddar Administrateur

  mars 2006 19:38 modifié #7

  dans 1143192785:

  
  des variables déclarées avant le @implementation (les fameuses sharedInstance notamment).
  

  
  
  D'accord, mais Bru, tu ne mets rien devant tes variables de méthode donc ?
• System

  mars 2006 19:38 modifié #8

  elles sont incluses de le 'le reste, c'est plutôt au pif'.
• muqaddar Administrateur

  mars 2006 19:38 modifié #9

  dans 1143193250:

  
  elles sont incluses de le 'le reste, c'est plutôt au pif'.
  

  
  
  mort de rire... ;-)
• tablier Membre

  mars 2006 19:38 modifié #10

  En principe (et suite aux corrections de Bru et Eddy58) mes variables commencent par une minuscule, les classes et les méthodes par une majuscule. Mes outlets commencent par o_ et mes actions par a_.
  Pour les pointeurs j'utilise char *c.  Je n'aime pas la formulation char* c que je trouve peu explicite. Quand aux noms, suivant l'humeur du jour, la hauteur de neige ou la longueur des bouchons sur la voie expresse, j'utilise soit des "_" soit des majuscules de séparation: lagentDuBoutDuPont ou bien  lagent_du_bout_du_pont.
  
• AliGator Membre, Modérateur

  mars 2006 19:38 modifié #11

  Pour ma part :
  - variables : minuscule pour la première lettre (et une majuscule que pour chaque lettre de début de mot, sauf donc le 1er), genre listOfCars
  - variables d'instances : j'essaye de respecter la règle de mettre un "_" au début, mais bon il m'arrive de zapper
  - variables de classes : assez rarement eu à  le faire, mais le "__" est une bonne habitude aussi
  - #define en toutes majuscule
  - autres constantes : commencent par k, genre kLocked
  
  Pour les "*", je les met personnellement accolées au type, mais j'avoue que du coup ça me "pose problème" lorsque je fais des déclarations multiples sur une ligne.
  Mais en général même si des fois ça serait plus concis, j'essaye de toute façon de ne déclarer qu'une variable par ligne. Surtout que ça permet de commenter chaque variable individuellement derrière
  
  Pour le type inclut dans le nom de variable, ça dépend si c'est assez clair ou pas, ça j'ai pas de règle stricte. En général je ne précise rien, sauf si c'est plutôt ambigu.
  
  Par contre pour les Outlets je met plus facilement le type abbrégé dans le nom comme pathField pour un NSTextField, okBtn pour un NSButton...
• Eddy58 Membre

  mars 2006 mars 2006 modifié #12

  Pour ma part :
  Déjà , je rattache toujours le pointeur à  la variable, ca évite à  confusion.
  -Variables d'instance : Commencent par une minuscule. Le underscore est à  réserver pour les variables privées. J'écris le type de la variable dans la variable pour les objets collection et de l'AppKit, ainsi dans le code on voit tout de suite à  quel type d'objet on a affaire.
  Ex.:[tt]
  IBOutlet NSSearchField *clientsSearchField;
  IBOutlet NSPopUpButton *modeListeClientsPopUpButton;
  NSMutableArray *clientsArray;
  [/tt]
  -Variables de classe : Commencent par deux underscore puis une minuscule, mais j'en utilise trés trés rarement.
  
  Voilà , sinon les Apple codings guidelines sont ici.
• Bru Membre

  mars 2006 19:38 modifié #13

  dans 1143205863:

  
  -Variables d'instance : Commencent par une minuscule. Le underscore est à  réserver pour les variables privées.

  
  
  "Variable privée" : ça n'a aucun sens en Objective-C, ou plus généralement en POO.
  Une variable d'instance est toujours privée, car c'est la justification même de la programmation objet (où les données sont sensées être toujours "opaques").
  
  D'ailleurs, par défaut, les variables d'instance sont en Obj-C @protected, ce qui fait qu'elles ne sont directement accessibles qu'à  la classe elle-même et à  ses sous-classes.
  
  Le @public est, de mon point de vue, une hérésie en POO.
  
  Par contre, je te rejoins sur le fait de préfixer les méthodes privées par _. D'autant plus qu'Apple ne se gène pas pour le faire.
  
  .
• Eddy58 Membre

  mars 2006 19:38 modifié #14

  dans 1143207890:

  
  

  dans 1143205863:

  
  -Variables d'instance : Commencent par une minuscule. Le underscore est à  réserver pour les variables privées.

  
  
  "Variable privée" : ça n'a aucun sens en Objective-C, ou plus généralement en POO.
  Une variable d'instance est toujours privée, car c'est la justification même de la programmation objet (où les données sont sensées être toujours "opaques").
  

  
  
  Tout à  fait Bru, je suis d'accord avec toi sur ce point là , et ce n'est pas moi qui irait le contredire, mais les diverses choses que j'ai lues sur le sujet font pourtant état de variables d'instances privées et de conventions associées, surtout en rapport avec les APIs Apple en faites afin d'éviter les conflits de noms.
  Les guidelines Apple :
  

  
  Do not use the underscore character as a prefix meaning that the instance variable is private. Apple reserves the use of this convention because its use by third parties could result in name-space collisions
  

  
  Et voici ce que raconte le Livre Cocoa Programming. Je met l'intégralité du paragraphe que je trouve trés intéressant et qui explique bien les conventions :
  

  
  Underscores and Usage
  A leading underscore character in a name conveys usage information. Any name that begins with an underscore character refers to an item that should only be used by the programmers who maintain the module in which the item is referenced. Names that begin with an underscore are part of private application programming interfaces (APIs) and are subject to change without notice. In most cases, the Objective-C compiler will not enforce usage rules. For example, _MYPrivateClass is the name of a class that should not be used by programmers other than the maintainers. MY is the prefix, and like all class names, the first letter of the first word in _MYPrivateClass is capitalized because class names have global scope. The Objective-C compiler will not prevent a programmer from creating an instance of _MYPrivateClass, but it is still a bad idea to do so.
  
  In Objective-C classes, private instance variables should begin with an underscore and a unique prefix. The prefix is essential for private instance variables because Apple reserves the right to add or change instances variables that begin with a single underscore character and no prefix. Using a prefix ensures that your instance variable names will not conflict with the names of any private instance variables that Apple uses. For example :
  [tt]
  int _myPrivateVariable; // private instance variable with prefix "my"
  [/tt]
  Names that do not begin with an underscore refer to items that are intended for use by all programmers. For example, all programmers should use the NSString class.
  
• muqaddar Administrateur

  mars 2006 19:38 modifié #15

  Moi je dis merci pour tous ces conseils.
  Je vais opérer de cette façon maintenant. Histoire d'être homogène entre toutes mes classes.
• AliGator Membre, Modérateur

  mars 2006 mars 2006 modifié #16

  - Je suis de même avis que vous pour la question des variables "publiques" et "privées" : quand je parlais de variables d'instances, c'était sous-entendu "privé" puisque je ne met pas de variables "publiques"
  
  - Concernant le préfixe : je ne l'utilise pas à  l'intérieur d'une classe (variables d'instance), par contre, comme la plupart d'entre vous j'imagine, je préfixe mes noms de classes par un préfixe relatif à  mon pseudo. C'est utile pour éviter les conflits si on passe nos classes à  d'autres ensuite
  
  Certains utilisent leurs initiales en majuscules, genre JBFace pour une classe Face créée par Jean Bonneau. Moi j'utilise le préfixe "ALI" (parfois "Ali").