Comment nommez-vous vos valeurs d'instance/paramètre ?

Question

Étant nouveau sur Objective-C (mais programmeur C/++ à long terme), je recherche des conseils/recommandations sur les conventions de dénomination des variables.

Ma préférence personnelle serait d'utiliser un préfixe pour les variables d'exemple à la fois pour plus de clarté dans les fonctions et pour éviter l'ombrage des paramètres de fonction.Cependant, je suis fan des propriétés qui excluent les préfixes (sauf si vous préfixez également les noms de vos propriétés, ce qui ne fonctionne pas très bien et semble stupide).De même, je pourrais utiliser la convention "self.variable", mais seulement si je fais de TOUT une propriété.

Alors, étant donné le code ci-dessous, quel est votre style de dénomination préféré pour les variables d'instance/fonction ?Et si cela ne vous dérange pas, comment gérez-vous l'observation des paramètres de fonction ?

@interface GridItem : NSObject
{
    CGRect _rect;
    ...  
}
@end

-(void) initFromRect:(CGRect)rect
{
    _rect = rect;
    ...
}

Acclamations!

Answer 1

La plupart des projets Cocoa utilisent la barre inférieure comme non-IBOutlet préfixe de variable d'instance et n'utilisez aucun préfixe pour IBOutlet variables d'instance.

La raison pour laquelle je n'utilise pas de barres de maintien IBOutlet Les variables d'instance sont que lorsqu'un fichier nib est chargé, si vous disposez d'une méthode de définition pour une prise connectée, ce paramètre sera appelé. Cependant ce mécanisme fait pas utilisez le codage clé-valeur, donc un IBOutlet dont le nom est préfixé par une barre de soulignement (par exemple. _myField) volonté pas être défini à moins que le setter soit nommé exactement comme la prise (par exemple. set_myField:), ce qui est non standard et brut.

Sachez également que l'utilisation de propriétés telles que self.myProp est pas la même chose que l'accès aux variables d'instance.Tu es envoyer un message lorsque vous utilisez une propriété, comme si vous utilisiez une notation entre crochets comme [self myProp].Tout ce que les propriétés font, c'est vous donner une syntaxe concise pour spécifier à la fois le getter et le setter sur une seule ligne, et vous permettre de synthétiser leur implémentation ;ils ne court-circuitent pas réellement le mécanisme d’envoi des messages.Si vous souhaitez accéder directement à une variable d'instance mais la préfixer avec self tu dois traiter self comme un pointeur, comme self->myProp qui est vraiment un accès aux champs de style C.

Enfin, n'utilisez jamais la notation hongroise lorsque vous écrivez du code Cocoa et évitez les autres préfixes comme "f" et "m_" - qui marqueront le code comme ayant été écrit par quelqu'un qui ne "comprend pas" et le fera être considéré avec méfiance par les autres développeurs de Cocoa.

En général, suivez les conseils du Directives de codage pour le cacao document au Connexion des développeurs Apple, et d'autres développeurs seront en mesure de comprendre et de comprendre votre code, et votre code fonctionnera bien avec toutes les fonctionnalités de Cocoa qui utilisent l'introspection d'exécution.

Voici à quoi pourrait ressembler une classe de contrôleur de fenêtre, en utilisant mes conventions :

// EmployeeWindowController.h
#import <AppKit/NSWindowController.h>

@interface EmployeeWindowController : NSWindowController {
@private
    // model object this window is presenting
    Employee *_employee;

    // outlets connected to views in the window
    IBOutlet NSTextField *nameField;
    IBOutlet NSTextField *titleField;
}

- (id)initWithEmployee:(Employee *)employee;

@property(readwrite, retain) Employee *employee;

@end

// EmployeeWindowController.m
#import "EmployeeWindowController.h"

@implementation EmployeeWindowController

@synthesize employee = _employee;

- (id)initWithEmployee:(Employee *)employee {
    if (self = [super initWithWindowNibName:@"Employee"]) {
        _employee = [employee retain];
    }
    return self;
}

- (void)dealloc {
    [_employee release];

    [super dealloc];
}

- (void)windowDidLoad {
    // populates the window's controls, not necessary if using bindings
    [nameField setStringValue:self.employee.name];
    [titleField setStringValue:self.employee.title];
}

@end

Vous verrez que j'utilise la variable d'instance qui fait référence à un Employee directement dans mon -init et -dealloc méthode, alors que j'utilise la propriété dans d'autres méthodes.C'est généralement un bon modèle avec des propriétés :Ne touchez jamais la variable d'instance sous-jacente pour une propriété dans les initialiseurs, dans -dealloc, ainsi que dans le getter et le setter pour la propriété.

Answer 2

Je suis les conseils de Chris Hanson concernant le préfixe de soulignement ivar, même si j'avoue que j'utilise également les traits de soulignement pour IBOutlets.Cependant, j'ai récemment commencé à déplacer mon IBOutlet déclarations au @property ligne, selon La suggestion de @mmalc.L'avantage est que tous mes ivars ont maintenant un trait de soulignement et que les setters KVC standard sont appelés (c'est-à-dire setNameField:).De plus, les noms des points de vente n'ont pas de traits de soulignement dans Interface Builder.

@interface EmployeeWindowController : NSWindowController {
@private
    // model object this window is presenting
    Employee *_employee;

    // outlets connected to views in the window
    NSTextField *_nameField;
    NSTextField *_titleField;
}

- (id)initWithEmployee:(Employee *)employee;

@property(readwrite, retain) Employee *employee;
@property(nonatomic, retain) IBOutlet NSTextField *nameField;
@property(nonatomic, retain) IBOutlet NSTextField *titleField;

@end

Answer 3

Vous pouvez utiliser le préfixe underbar sur vos ivars tout en utilisant le nom autre que underbar pour vos propriétés.Pour les accesseurs synthétisés, faites simplement ceci :

@synthesize foo = _foo;

Cela indique au compilateur de synthétiser la propriété foo en utilisant le ivar_foo.

Si vous écrivez vos propres accesseurs, vous utilisez simplement l'ivar underbar dans votre implémentation et conservez le nom de la méthode non underbar.

Answer 4

Personnellement, je suis les conventions de dénomination Cocoa, en utilisant la casse chameau pour les fonctions et les variables, et la casse chameau en majuscule pour les noms d'objets (sans le NS bien sûr).

Je trouve que le préfixe de type rend le code plus opaque pour quiconque ne l'a pas écrit (puisque tout le monde utilise invariablement des préfixes différents), et dans un IDE moderne, il n'est pas vraiment si difficile de déterminer le type de quelque chose.

Answer 5

Avec l'introduction des propriétés, je ne vois pas la nécessité de préfixer "_" aux variables d'instance de classe.Vous pouvez définir une règle simple (décrite dans votre fichier d'en-tête) selon laquelle toutes les variables accessibles en dehors de la classe doivent être accessibles via la propriété ou en utilisant des méthodes personnalisées sur la classe pour affecter les valeurs.Cela me semble beaucoup plus propre que d'avoir des noms avec "_" collés devant eux.Il encapsule également correctement les valeurs afin que vous puissiez contrôler la façon dont elles sont modifiées.

Answer 6

Je n'aime pas utiliser les traits de soulignement comme préfixes pour les identifiants, car C et C++ réservent tous deux certains préfixes de soulignement à l'usage de l'implémentation.

Je pense qu'utiliser "self.variable" est moche.

En général, j'utilise des identifiants simples (c'est-à-dire sans préfixes ni suffixes) pour les variables d'instance.Si votre classe est si compliquée que vous ne vous souvenez plus des variables d'instance, vous avez des problèmes.Donc, pour votre exemple, j'utiliserais "rect" comme nom de la variable d'instance et "newRect" ou "aRect" comme nom de paramètre.

Answer 7

André :En fait, de nombreux développeurs Cocoa n'utilisent pas du tout de préfixes de variables d'instance.C'est également extrêmement courant dans le monde Smalltalk (en fait, je dirais qu'il est presque inconnu dans Smalltalk d'utiliser des préfixes sur des variables d'instance).

Les préfixes sur les variables d'instance m'ont toujours semblé être un isme C++ qui a été transféré à Java puis à C#.Étant donné que le monde Objective-C était en grande partie parallèle au monde C++, alors que les mondes Java et C# en sont les successeurs, cela expliquerait la différence « culturelle » que vous pourriez voir à ce sujet entre les différents groupes de développeurs.

Answer 8

Mon style est hybride et vraiment un vestige de l'époque de PowerPlant :

Les préfixes les plus utiles que j'utilise sont « in » et « out » pour les paramètres de fonction/méthode.Cela vous aide à savoir à quoi servent les paramètres en un coup d'œil et aide réellement à éviter les conflits entre les paramètres de méthode et les variables d'instance (combien de fois avez-vous vu le paramètre "table" entrer en conflit avec une variable d'instance du même nom).Par exemple.:

- (void)doSomethingWith:(id)inSomeObject error:(NSError **)outError;

Ensuite, j'utilise le nom nu pour les variables d'instance et les noms de propriétés :

Ensuite, j'utilise "le" comme préfixe pour les variables locales :laTable, l'URL, etc.Encore une fois, cela permet de différencier les variables locales et d'instance.

Ensuite, après le style PowerPlant, j'utilise une poignée d'autres préfixes :k pour les constantes, E pour les énumérations, g pour les globales et s pour la statique.

J'utilise ce style depuis environ 12 ans maintenant.

Answer 9

Même si j'aime utiliser le préfixe de soulignement pour les ivars, je déteste écrire @synthesize lignes à cause de toutes les duplications (c'est pas très SEC).J'ai créé une macro pour aider à cela et réduire la duplication de code.Ainsi, au lieu de :

@synthesize employee = _employee;

J'écris ceci :

ddsynthesize(employee);

Il s'agit d'une simple macro utilisant le collage de jetons pour ajouter un trait de soulignement sur le côté droit :

#define ddsynthesize(_X_) @synthesize _X_ = _##_X_

Le seul inconvénient est que cela confondra l'outil de refactoring de Xcode et qu'il ne sera pas renommé si vous renommez la propriété en refactorisant.

Answer 10

En plus de ce qui a été dit ici, assurez-vous de lire la documentation Cocoa sur la dénomination conforme à l'observation des valeurs clés.Suivre strictement ce modèle vous aidera grandement à long terme.