Hoe doen jy die naam van jou instansie/param waardes?

Question

Om nuwe Doel-C (maar'n lang termyn C/++) programmeerder ek is op soek na advies/aanbevelings oor die benaming konvensies vir veranderlikes.

My persoonlike voorkeur sou wees om te gebruik'n voorvoegsel byvoorbeeld veranderlikes beide vir duidelikheid binne funksies en om te verhoed dat die oorskadu van die funksie parameters.Maar ek is'n fan van die eienskappe wat reëls uit voorvoegsels (tensy jy ook voorvoegsel jou eiendom name, wat nie werk nie te goed en lyk daft).Net so ek kon gebruik om die "self.veranderlike" konvensie, maar net as ek maak ALLES'n eiendom.

So gegewe die kode hieronder wat is jou voorkeur benaming styl vir instansie/funksie veranderlikes?En as jy nie die moeite doen, hoe hanteer jy met oorskadu op die funksie params?

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

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

Cheers!

Answer 1

Die meeste Kakao projekte gebruik underbar as'n nie-IBOutlet byvoorbeeld veranderlike voorvoegsel, en gebruik geen voorvoegsel vir IBOutlet byvoorbeeld veranderlikes.

Die rede waarom ek nie gebruik underbars vir IBOutlet byvoorbeeld veranderlikes is dat wanneer'n nib lêer is gelaai, as jy het'n setter metode vir'n verbind uitlaat, wat setter sal genoem word. Maar hierdie meganisme nie nie gebruik die Sleutel-Waarde Kodering, so'n IBOutlet wie se naam is voorafgegaan met'n underbar (bv. _myField) sal nie ingestel word nie, tensy die setter is vernoem presies soos die uitlaat (bv. set_myField:), wat nie-standaard-en bruto.

Ook, wees bewus daarvan dat die gebruik van eienskappe soos self.myProp is nie dieselfde as toegang tot byvoorbeeld veranderlikes.Jy is stuur'n boodskap wanneer jy gebruik maak van'n eiendom, net soos as jy gebruik bracket notasie soos [self myProp].Alle eiendomme doen is gee jou'n bondige sintaksis vir die spesifiseer van beide die getter en setter in'n enkele lyn, en toelaat dat jy om te sintetiseer hul implementering;hulle doen eintlik nie kort-kring die boodskap versending meganisme.As jy wil om toegang tot'n instansie veranderlike direk nie, maar voorvoegsel dit met self wat jy nodig het om te behandel self as'n wyser, soos self->myProp wat is regtig'n C-styl veld toegang.

Ten slotte, nog nooit gebruik hongaarse notasie toe te skryf Kakao kode, en skaam weg van die ander voorvoegsels soos "f" en "m_" — wat sal merk die kode soos wat geskryf is deur iemand wat nie "kry dit" en sal veroorsaak dat dit om te besigtig word deur die vermoede deur ander Kakao ontwikkelaars.

In die algemeen, volg die advies in die Kodering Riglyne vir Kakao dokument by die Apple Ontwikkelaar Verband, en ander ontwikkelaars sal in staat wees om af te haal en te verstaan jou kode, en jou kode sal goed werk met al die Kakao funksies wat gebruik runtime introspeksie.

Hier is wat'n venster kontroleerder klas kan lyk, met behulp van my konvensies:

// 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

Jy sal sien dat ek met behulp van die instansie veranderlike wat verwysings'n Employee direk in my -init en -dealloc metode, terwyl ek die gebruik van die eiendom in ander metodes.Dit is oor die algemeen'n goeie patroon met eienskappe:Altyd net raak die onderliggende byvoorbeeld veranderlike vir'n eiendom in initializers, in -dealloc, en in die getter en setter vir die eiendom.

Answer 2

Ek volg advies Chris Hanson se met betrekking tot die underscore Ivar voorvoegsel, alhoewel ek erken ek gebruik onderstreping se vir IBOutlets sowel. Maar ek het onlangs begin beweeg my IBOutlet verklarings aan die @property lyn, soos per @ voorstel mmalc se . Die voordeel is dat al my ivars het nou 'n onderstreep en standaard KVC etters is geroep (maw setNameField:). Ook, die uitlaat name nie onderstreping het in Interface Bouwer.

@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

Jy kan die underbar voorvoegsel gebruik op jou ivars en steeds die nie-underbar naam vir jou eiendom. Vir gesintetiseer Toegangers, hierdie net doen:

@synthesize foo = _foo;

Dit sê die samesteller van die eiendom cat sintetiseer met behulp van the_foo Ivar.

As jy jou eie Toegangers skryf, dan kan jy net gebruik die underbar Ivar in jou implementering en hou die nie-underbar metode naam.

Answer 4

Persoonlik, volg ek die Cocoa benoemings konvensies, met behulp van die kameel-omhulsel vir funksies en veranderlikes, en gekapitaliseer kameel-omhulsel vir voorwerp name (sonder die voorste NS natuurlik).

Ek vind tipe voorvoegsel maak code meer ondeursigtig aan enigiemand wat nie skryf dit (sedert almal sonder uitsondering gebruik verskillende voorvoegsels), en in 'n moderne IDE dit is nie regtig so moeilik om uit te vind tipe iets se.

Answer 5

Met die bekendstelling van eiendomme sien ek geen rede vir voorvoegsel "_" klas byvoorbeeld veranderlikes. Jy kan 'n eenvoudige reël (in jou kop lêer beskryf) wat enige veranderlikes buite die klas te verkry moet verkry word via die eiendom, of deur die gebruik van persoonlike metodes van die klas om waardes beïnvloed stel. Dit vir my lyk baie skoner as om name met "_" vas op die voorkant van hulle. Dit is ook goed saamvat die waardes sodat jy kan bepaal hoe hulle verander het.

Answer 6

Ek hou nie van die gebruik onderstreping as voorvoegsels vir enige identifiseerders, want C en C ++ beide behou sekere underscore voorvoegsels vir gebruik deur die implementering daarvan.

Ek dink die gebruik van "self.variable" is lelik.

In die algemeen, ek gebruik onversierde identifiseerders (dit wil sê, geen voorvoegsels nie agtervoegsels) byvoorbeeld veranderlikes. As jou klas is so ingewikkeld dat jy nie die geval veranderlikes kan onthou, is jy in die moeilikheid. So vir jou voorbeeld, sou ek "rect" gebruik as die naam van die instansie veranderlike en "newRect" of "aRect" as die naam parameter.

Answer 7

Andrew: Daar is eintlik baie Cocoa ontwikkelaars wat nie gebruik byvoorbeeld veranderlike voorvoegsels at all. Dit is ook baie algemeen in die Smalltalk wêreld (in werklikheid, sou ek sê dit is byna ongehoord in Smalltalk om voorvoegsels op byvoorbeeld veranderlikes gebruik).

Voorvoegsels op byvoorbeeld veranderlikes was nog altyd my opgeval het as 'n C ++ - ism wat oor gebring na Java en dan na C #. Sedert die Objective-C wêreld grootliks parallel met die C ++ wêreld was, waar as die Java en C # wêrelde is opvolgers om dit, wat sou die "kulturele" verskil jy kan sien op hierdie tussen die verskillende stelle van ontwikkelaars te verduidelik.

Answer 8

My styl is hibriede en regtig 'n oorblyfsel van die verbeten uit kragbron dae:

Die mees bruikbare voorvoegsels Ek gebruik is "in" en "uit" vir funksie / metode parameters. Dit help jou om te weet wat die parameters is vir 'n oogopslag en help regtig konflikte tussen metode parameters en byvoorbeeld veranderlikes (hoeveel keer het jy die parameter "tafel" konflik met 'n geval veranderlike met dieselfde naam gesien) te voorkom. Bv:.

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

Toe ek gebruik die kaal naam byvoorbeeld veranderlikes en name eiendom:

Toe ek gebruik "die" as 'n voorvoegsel vir plaaslike veranderlikes:. TheTable, theURL, ens Weereens dit help onderskei tussen plaaslike en en byvoorbeeld veranderlikes

Toe volgende kragbron stilering Ek gebruik 'n handvol van die ander voorvoegsels:. K vir konstantes, E vir enums, g vir globals, en s vir statika

Ek het al met behulp van hierdie styl vir iets soos nou 12 jaar.

Answer 9

Hoewel ek is lief vir die gebruik van die onderstreepkarakter voorvoegsel vir ivars, Ek verfoei my lewe skryf @synthesize lyne as gevolg van al die duplisering (dit is nie baie DRY ). Ek het 'n makro te help doen dit en verminder kode duplisering. So, in plaas van:

@synthesize employee = _employee;

ek hier skryf:

ddsynthesize(employee);

Dit is 'n eenvoudige makro behulp teken plak om 'n onderstreep toe te voeg tot die regterhand:

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

Die enigste nadeel is dat dit Xcode se refactoring gereedskap sal verwar, en dit sal nie ontslae herdoop, as jy die eiendom hernoem deur refactoring.

Answer 10

Saam met wat hier gesê is, is seker om die Cocoa dokumentasie oor Sleutel Waarde Waarneming voldoen benaming lees. Streng volgens hierdie patroon sal jy baie help in die lang termyn.