5 Stimmen

Namenskonventionen in Objective C /C , die mit "_" beginnen?

Ich sehe, dass manche Leute die Variable wie folgt definieren:

b2World *_world;
b2Body *_body;
CCSprite *_ball;

anstelle von

b2World *world;
b2Body *body;
CCSprite *ball;

Die zweite ist mir bekannt, aber nicht die erste. Also habe ich in der Wikipedia nachgesehen, wie die Namenskonvention aussieht:

Namen, die mit einem doppelten Unterstrich beginnen oder einem Unterstrich und einem Großbuchstaben sind reserviert für die Implementierung (Compiler, Standardbibliothek) reserviert und sollten nicht verwendet werden (z.B. __reserved oder _Reserved).

Hat es also eine besondere Bedeutung, wenn es mit "_" beginnt?

Der Code, den ich gesehen habe und der mit "_" beginnt, ist hier:

http://www.raywenderlich.com/457/intro-to-box2d-with-cocos2d-tutorial-bouncing-balls

Die Wikiseite.

13voto

jlehr Punkte 15365

Bei einigen Objective-C-Entwicklern ist es seit langem üblich, Instanzvariablen einen Unterstrich voranzustellen. Das kann in mehrfacher Hinsicht hilfreich sein: Erstens macht es die Erkennung von Instanzvariablen in einer .m-Datei einfacher; zweitens entlastet es die Entwickler davon, sich kreative Namen für Methodenparameter einfallen lassen zu müssen, um Kollisionen mit den Namen von Instanzvariablen zu vermeiden; und drittens zeigt es, wie bereits von anderen bemerkt, an, dass die Instanzvariablen privat sind und daher nicht wahllos im gesamten Code aufgerufen werden sollten.

Ich würde sogar dafür plädieren, den direkten Zugriff auf Instanzvariablen in anderen Methoden als Accessors (Getter und Setter) zu vermeiden, -dealloc y -init... . Das heißt nicht, dass Sie sie niemals irgendwo anders verwenden sollten, aber Sie sollten zumindest darüber nachdenken, bevor Sie eine Instanzvariable direkt in anderen Methoden verwenden.

3voto

cutsoy Punkte 9969

Das ist wirklich sehr hilfreich, aber die meisten Leute wissen nicht, warum, und das ist schade. Apple verwendet Unterstriche, um die Art und Weise, wie andere Objekte auf die Variablen eines bestimmten Objekts zugreifen, von der Art und Weise zu trennen, wie ein bestimmtes Objekt auf seine eigenen Variablen zugreift. Das mag jetzt etwas seltsam klingen, aber stellen Sie sich Folgendes vor: Sie kennen wahrscheinlich alle die folgende Compilerwarnung

.h
@property (nonatomic, retain, readonly) UITableView *tableView;

.m
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
    return [self loadSomethingElseForTableView:tableView];
}

Dies führt zu einer Compiler-Warnung, da er nicht weiß, ob Sie auf die lokale Variable "tableView" oder die Instanzvariable verweisen. Apple empfiehlt Ihnen daher, am Anfang Ihrer @Implementierung Folgendes hinzuzufügen.

@synthesize tableView = _tableView;

Wenn Sie sich nun auf _tableView weiß der Compiler, dass Sie die Instanzvariable und nicht die lokale Variable meinen.

Dies macht es auch viel einfacher, die Garbage Collection in Obj-C zu verstehen und häufige Fehler zu vermeiden.

Zum Beispiel, wenn Sie das Folgende tun:

@property (nonatomic, retain, readonly) NSString *title;

- (id)initWithTitle:(NSString *)title {
    if ((self = [super init])) {
        self.title = title; // Is not possible, since it's read only.
        title = title; // Is not possible, since it's the same (local) variable.
        // Changing the method to initWithTitle:(NSString *)aTitle;
        title = aTitle;
    }
    return self;
}

Da Sie den Standard-Setter nicht verwenden (eigentlich können Sie das nicht, da er schreibgeschützt ist), müssen Sie brauchen um die Variable selbst zu behalten. Dies ist viel einfacher zu merken, wenn Sie jeder Instanzvariablen ein Präfix geben (damit Sie wissen, dass Sie sie selbst behalten müssen).

Grundsätzlich ist es also wichtig, den Unterschied zwischen self.variable und ( _ ) variable . (d.h.: self.variable Karten zu [self setVariable:...] y variable wird direkt auf Ihren Zeiger abgebildet.

Wenn Sie sie außerdem als private Variable hinzufügen, wie hier:

@interface TSSomeObject : NSObject {
@private
    NSString *_privateTitle;
}
@end

Der Unterstrich ist nicht wirklich notwendig, es sei denn, Sie stoßen auf lokale Variablen mit demselben Namen. Abgesehen davon ist es auch eine einfache Möglichkeit, Sie daran zu erinnern, dass es sich um einen lokalen Zeiger handelt und dass Sie die Variable behalten (und freigeben) müssen, wenn Sie sie Ihrem Objekt zuweisen.

Was ist falsch ist es, eine Eigenschaft mit einem Unterstrich-Präfix zu erstellen, etwa so:

@property (nonatomic, retain) NSString *_title;

Das ist wirklich falsch, und ich werde nicht einmal erklären, warum ;)


Also ja! Sie sollten wirklich Unterstrich-Präfixe verwenden, es macht Ihren Code viel einfacher zu lesen, und durch den Compiler zu interpretieren! In Xcode 4 hat Apple sogar diese @synthesize s zu den Standardvorlagen.

0voto

Michael Mrozek Punkte 160867

Normalerweise werden sie für Variablen verwendet, auf die außerhalb der aktuellen Datei/Modul/Namensraum/was auch immer nicht zugegriffen werden soll, in Sprachen, die den Zugriff nicht mit etwas wie einer private Stichwort

0voto

Pork 'n' Bunny Punkte 6710

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284-1001757

Sowohl nach der Konvention als auch nach der Empfehlung im obigen Dokument sollten Sie ivars einen Unterstrich vorangestellt haben.

Allerdings handelt es sich um einen Verweis auf explizit festgelegte Ivarwerte für Eigenschaften.

Aber der Gebrauch ist derselbe, um auf die Verwendung eines Ivar hinzuweisen, wo immer er gesehen wird.

Ich bin jedoch offen für die Möglichkeit, dass in diesem Zusammenhang die Verwendung eines Unterstrichs mit vorangestelltem ivar dem Benutzer signalisieren könnte, dass er etwas falsch macht. In der Zwischenzeit könnte ein nachgestellter Unterstrich für reine Ivars verwendet werden, auf die direkt zugegriffen werden soll.

In diesem Blog finden Sie einige gute Gedanken von einem erfahrenen Praktiker, der empfiehlt, Unterstriche voranzustellen.

http://blog.bignerdranch.com/463-a-motivation-for-ivar-decorations/

Unabhängig davon, ob Sie Ihre eigenen Efeuzeichen mit vorangestellten Unterstrichen ausschmücken, gibt es zumindest einige Hinweise darauf, dass eine Art der Verzierung dazu beiträgt, Fehler zu vermeiden. Und vorangestellte Unterstriche sind die häufigste Verzierung.

-1voto

JeremyP Punkte 81782

Apple reserviert Namen, die mit einem Unterstrich beginnen, für seine eigenen privaten Ivars und Methoden. In Objective-C auf jeder Apple-Plattform wird empfohlen, den Bezeichnern keinen Unterstrich voranzustellen.

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingMethods.html

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X