Cum vă numiți valorile instanței/paramului?

Fiind noul programator Obiectiv-C (dar un C/++ pe termen lung) caut sfaturi/recomandari privind conventiile de numire pentru variabile.

Preferința mea personală ar fi să folosesc un prefix, de exemplu variabile, atât pentru claritate în cadrul funcțiilor, cât și pentru a preveni umbrirea parametrilor funcției. Cu toate acestea, sunt un fan al proprietăților care exclude prefixele (cu excepția cazului în care prefixați și numele proprietăților dvs., care nu funcționează prea bine și arată deloc). În mod similar aș putea folosi convenția "auto-variabilă", dar numai dacă aș face EVOLUȚIA o proprietate.

Deci, având codul de mai jos, care este stilul tău preferat de numire pentru variabilele de exemplu/funcție? Și dacă nu vă deranjezi, cum faceți față cu umbrirea pe parametrii de funcționare?

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

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

Noroc!

0
fr hi bn

10 răspunsuri

Nu îmi place să folosesc sublinierii ca prefixe pentru orice identificatori, deoarece C și C ++ rezervă ambele prefixe de subliniere pentru utilizarea de către implementare.

Cred că "self.variable" este urât.

În general, folosesc identificatori neadornați (adică nu există prefixe sau sufixe), de exemplu variabilele. Dacă clasa ta este atât de complicată încât nu-ți poți aminti variabilele de instanță, ai probleme. Deci, pentru exemplul dvs., aș folosi numele "rect" ca numele variabilei instanță și "newRect" sau "aRect" ca nume de parametru.

0
adăugat

Odată cu introducerea proprietăților, nu văd nevoia de a prefixa "_" la variabilele instanței de clasă. Puteți stabili o regulă simplă (descrisă în fișierul antetului dvs.) că toate variabilele care trebuie accesate în afara clasei trebuie să fie accesate prin proprietate sau prin utilizarea metodelor personalizate din clasă pentru a afecta valorile. Acest lucru pentru mine pare mult mai curat decât având nume cu "_" blocat pe partea din față a acestora. De asemenea, încapsulează corect valorile astfel încât să puteți controla modul în care acestea sunt modificate.

0
adăugat

Majoritatea proiectelor de cacao folosesc sub bara ca prefix de prefix al instanței non-code IBOutlet și nu folosesc prefix pentru variabilele de instanță IBOutlet .

Motivul pentru care nu folosesc barele de bare pentru variabilele de instanță IBOutlet este că atunci când este încărcat un fișier nib, dacă aveți o metodă de setare pentru o priză conectată, acel setter va fi apelat. Cu toate acestea acest mecanism nu utilizează codarea de cod cheie, deci un IBOutlet al cărui nume este prefixat cu un bare de sub ( de exemplu _myField < cod <>> set_myField: ), care este nestandard și brut .

Also, be aware that using properties like self.myProp is not the same as accessing instance variables. You are sending a message when you use a property, just like if you used bracket notation like [self myProp]. All properties do is give you a concise syntax for specifying both the getter and setter in a single line, and allow you to synthesize their implementation; they do not actually short-circuit the message dispatch mechanism. If you want to access an instance variable directly but prefix it with self you need to treat self as a pointer, like self->myProp which really is a C-style field access.

În cele din urmă, nu utilizați niciodată o notație maghiară atunci când scrieți codul de cacao și nu vă mai folosiți de alte prefixe precum "f" și "m_"? care va marca codul ca fiind scris de cineva care nu-l "primește" și îl va face să fie privit de suspiciune de alți dezvoltatori de cacao.

În general, urmați recomandările din Codificare Ghidul pentru cacao document la Conexiune dezvoltator Apple și alți dezvoltatori va fi capabil să înțeleagă și să înțeleagă codul dvs., iar codul dvs. va funcționa bine cu toate funcțiile de cacao care utilizează introspecția de runtime.

Iată ce ar putea arăta o clasă de controlor de ferestre, folosind convențiile mele:

// EmployeeWindowController.h
#import 

@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

Veți vedea că folosesc variabila de instanță care trimite un Angajat direct în metoda mea -init și -dealloc m folosind proprietatea în alte metode. Acesta este, în general, un model bun cu proprietăți: atingeți numai variabila de bază a unei proprietăți în inițiale, în -dealoc și în getter și setter pentru proprietate.

0
adăugat
...și? Asta nu face o idee bună. :)
adăugat autor Chris Hanson, sursa
Prefixul UITextView al Apple prefixează ivars cu m_.
adăugat autor Christopher Lloyd, sursa

Andrew: Există de fapt o mulțime de dezvoltatori de cacao care nu folosesc deloc prefixe de exemplu. De asemenea, este extrem de comună în lumea Smalltalk (de fapt, aș spune că este aproape nemaipomenit în Smalltalk să utilizeze prefixe pentru variabilele de instanță).

Prefixele pentru variabilele de instanță mi-au întors întotdeauna ca un C ++ care a fost adus la Java și apoi la C #. Deoarece lumeaobjective-ca fost în mare parte paralelă cu lumea C ++, unde lumile Java și C# sunt succesoare, aceasta ar explica diferența "culturală" pe care ați putea-o vedea între diferitele seturi de dezvoltatori.

0
adăugat

Împreună cu ceea ce sa spus aici, asigurați-vă că ați citit documentația despre cacao pe denumirea compatibilă a valorii cheie. Urmărirea strictă a acestui model vă va ajuta foarte mult pe termen lung.

0
adăugat

Stilul meu este hibrid și într-adevăr un holdover din zilele PowerPlant:

Cele mai folositoare prefixe pe care le folosesc sunt "in" și "out" pentru parametrii funcției/metodei. Acest lucru vă ajută să știți care sunt parametrii dintr-o privire și vă ajută într-adevăr să preveniți conflictele dintre parametrii metodelor și variabilele de instanță (de câte ori ați văzut conflictul de parametru "tabel" cu o variabilă de instanță cu același nume). De exemplu.:

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

Apoi folosesc numele gol pentru variabile și nume de proprietăți:

Apoi folosesc "the" ca prefix pentru variabilele locale: theTable, theURL, etc. Din nou, acest lucru ajută la diferențierea între variabilele locale și instanță.

Apoi, după stilul PowerPlant, folosesc o mână de alte prefixe: k pentru constante, E pentru enums, g pentru globale și s pentru statică.

Am folosit acest stil pentru ceva de 12 ani.

0
adăugat
Nu sunt convins de chestia k, E, g și s, dar îmi place ideea de a adăuga și a ieși.
adăugat autor Steven Fisher, sursa

Urmăresc sfatul lui Chris Hanson în ceea ce privește prefixul subliniază ivar, deși recunosc că folosesc și sublinierea pentru IBOutlets. Cu toate acestea, recent am început să mișc declarațiile mele IBOutlet pe linia @property , ca pe @ sugestia lui mmalc . Beneficiul este că toate ivars-urile mele au acum un setter KVC de subliniere și standard (denumite setNameField: ). De asemenea, numele de ieșire nu au subliniere în 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
0
adăugat
Aceasta este de fapt ceea ce fac acum, datorită sprijinului IB pentru IBOutlet pe proprietăți. :)
adăugat autor Chris Hanson, sursa

While I love using the underscore prefix for ivars, I loathe writing @synthesize lines because of all the duplication (it's not very DRY). I created a macro to help do this and reduce code duplication. Thus, instead of:

@synthesize employee = _employee;

Eu scriu aceasta:

ddsynthesize(employee);

Este o macrocomandă simplă care folosește token pentru a adăuga o subliniere spre partea dreaptă:

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

Singurul dezavantaj este că va confunda instrumentul de refactorizare al lui Xcode și nu va mai fi redenumit dacă îl redenumiți prin refactorizare.

0
adăugat

Personal, urmăresc convențiile de numire a cocoașilor, folosind cămășu pentru funcții și variabile și caractere capitalizate pentru cămăși pentru nume de obiect (fără a conduce, bineînțeles, NS).

Mi se pare că prefixarea de tip face ca codul să fie mai opac pentru oricine nu l-a scris (deoarece toți folosesc în mod invariabil prefixe diferite), iar într-un IDE modern nu este chiar așa de greu să-ți dai seama de ceva.

0
adăugat

Puteți utiliza prefixul sub bare de pe ivars și utilizați în continuare numele non-underbar pentru proprietățile dvs. Pentru accesoriile sintetizate, faceți acest lucru:

@synthesize foo = _foo;

Acest lucru îi spune compilatorului să sintetizeze proprietatea foo folosind the_foo ivar.

Dacă vă scrieți proprii accesori, atunci folosiți linia de sub bare din implementarea dvs. și păstrați numele metodei care nu este sub bare.

0
adăugat