Cette question concerne le style de nommage variable dans l'objectif C et le cacao. Je veux juste souligner que je ne cherche pas une "bonne" réponse, de bonnes idées.
J'ai lu via les guides de style C Apple et Google de Google et je ne suis pas vraiment content d'eux. Le guide d'Apple n'a pas de recommandations de style réel concernant les variables d'instance VS Variables locales. En fait, la bibliothèque de cacao lui-même semble parfaitement heureux d'avoir des paramètres de fonction du même nom exactement que les variables d'instance. Cela me fait grincer personnellement.
Guide Googles Spécifie que les variables d'instance doivent être indiquées avec un soulignement de fin. D'accord, bien et bien, mais cela suggère que nous synthétisez ensuite chaque propriété publique avec @synthesize Property = Property_. Je ne connais pas à personne d'autre, mais je serai damné si je vais faire cela pour chaque variable d'instance de mon projet. Je pense que c'est une solution inutile et déroutante.
Je suis tenté d'aller avec le myx (par exemple, «myInstanceVariable») Style de nommage pour les propriétés d'objet, mais j'ai rarement vu ce style dans l'objectif c.
Alors oui, qu'est-ce que vous utilisez? Toute convention de style, je ne sais pas à ce sujet que vous avez trouvé utile? Pensez-vous que les paramètres de fonction avec le même nom que les variables d'instance sont dangereux, en particulier dans plusieurs environnements de développeurs? Merci gars et filles!
Note - Autant de personnes l'ont signalé, ma terminologie était désactivée dans l'OP. Toutes mes excuses si le libellé original fait mal à la clarté, mais je pense que le point était toujours clair.
5 Réponses :
M_VARIABLENAME est assez courant aussi pour les variables des membres.
Personnellement, la plupart du temps, je viens d'aller avec le même nom pour les deux variables et de faire la distinction entre this.varname et varname . .
Ouais j'ai vu M_X occasionnellement, mais avec la convention de réglage dans l'objectif C, il semble désordonné. SETM_VARIABLENAME? Je suppose que si vous vous tenez à la notation de points, vous évitez cela.
Le préfixe "m_" est une mauvaise habitude. Il en va de même pour le soulignement unique, à moins que vous n'ayez écrit de code pour une utilisation interne à Apple. Malheureusement, Apple a laissé un certain nombre de projets de code d'échantillon dans les rues sans nettoyage approprié.
Pourquoi est-ce que _foo est une mauvaise habitude? Apple ne peut pas ajouter de ivars au code Obj-C 1.0, afin qu'ils ne puissent pas casser la vôtre. Et si je comprends bien, le compilateur les ajuste à OBJ-C 2.0 afin que, bien que Apple puisse casser la compilation de votre code (facile à réparer), des programmes déjà compilés continueront de fonctionner.
dans le cacao, le style est d'avoir des pascalasés (ou est ce camelicad? Je ne peux jamais me souvenir) des noms; et les variables de membre sont-elles nommées les mêmes que les méthodes d'accesseur. (Tels que Ce n'est peut-être pas le meilleur style, mais c'est probablement une bonne idée de s'y habituer si vous allez effectuer une quantité de travail avec cacao, comme un certain nombre de mécanismes supposent ce type de convention de dénomination particulière. Nsinteger aninteger , - aninteger et - Setaninteger: ).
Bien sûr, je suis au courant des conventions mandatées par le getter / Setter, et je ne voudrais pas vous écarter de l'affaire Camel. Ma question est plus dans le sens de la notation utilisée pour signifier la différence entre une instance et une variable membre. En fait, vous pouvez synthétiser des méthodes d'accesseur avec n'importe quel nom pour toute variable que dans le style Google, mais cela pourrait être très déroutant imo.
J'ai tendance à utiliser des noms de variable non préfixés (Notez que "la variable de membre" est un ism C ++, car il est suggérant des structures et des classes principalement interchangeables, ce qui n'est pas le cas dans Objective-c), et dans les cas où l'ambiguïté se pose, j'utilise la convention SmallTalk de nommer le paramètre (Bien sûr, dans l'OBJC moderne, vous utiliseriez une propriété pour cela.) Utilisation Notez que le thefoo au lieu de AFOO est également un peu commun ; Voir les réponses à Cette question . < P> La Convention Google a du sens si vous êtes vraiment inquiet pour les conflits. Si vous utilisez un Macro de texte XCode ou un outil comme Dictionnaire d'achèvement ou Accessorizer Pour générer vos directives, il est assez simple à adopter.
Bonne réponse. J'accepte que le préfixe du paramètre est plus propre que d'essayer de chaussette une convention dans des variables d'instance C objectif C. Les Documents Apple décrivent des conventions pour cela dans le cas des types de NsObject communs, ce qui la prolongeait pour vos propres types est parfaitement logique. Je marquais cela comme la réponse, car il a le mieux répondu au point principal de ma question - éviter l'espacement des noms ambiguës dans les fonctions de classe - et n'ajoute aucune étrange conventions ni de travail.
Premier: il n'y a pas de "variables de membre" dans Objective-C, il existe des "variables d'instance" ou "ivars".
Google n'est pas une autorité sur le codage de l'objectif c ou le développement de Mac. Google Earth est une application QT: 'Nuff dit.
Il semble que je me souvienne de voir un guide de style de codage officiel de Apple pour Objective-C, que je ne trouve pas pour le moment. Cet article est un assez bon résumé, cependant:
http://cocoadevcentral.com/articles/000082.php
trouvé! Voici les directives de codage officielles d'Apple pour le cacao:
Merci de relier les lignes directrices Apple. Je pense que le reste de ceci est en dehors du sujet. Tout le monde semble désireux de tirer parti de leurs connaissances de la taxonomie de la terminologie C, mais de ne pas répondre à la question à portée de main. En outre, Google n'a peut-être pas inventé l'objectif C, mais ils sont certainement une source valide en matière de codage des conventions. Dans ce cas, je ne pense pas que les documents Apple étaient explicitement clairs sur cela et Google est. Je n'aime pas aimer leur réponse.
_foo n'est pas une mauvaise habitude. Ou au moins ce n'est plus plus. Voir: