Как вы называете значения экземпляров/параметров?

Будучи новичком в Objective-C (но уже давно программирующим на C/++), я ищу совета/рекомендации по соглашениям об именовании переменных.

Лично я предпочитаю использовать префикс для переменных экземпляра как для ясности внутри функций, так и для предотвращения затенения параметров функций. Однако я являюсь поклонником свойств, что исключает использование префиксов (если только вы не используете префикс для имен ваших свойств, что работает не слишком хорошо и выглядит глупо). Аналогично я могу использовать соглашение "self.variable", но только если я сделаю КАЖДОЕ свойство свойством.

Итак, учитывая приведенный ниже код, какой стиль именования переменных экземпляра/функции вы предпочитаете? И если вас это не беспокоит, как вы справляетесь с тенью на параметрах функций?

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

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

Будьте здоровы!

Решение

Большинство проектов Cocoa используют underbar в качестве префикса переменной экземпляра, не являющейся IBOutlet, и не используют префикс для переменных экземпляра IBOutlet.

Причина, по которой я не использую underbar для переменных экземпляра IBOutlet, заключается в том, что при загрузке nib-файла, если у вас есть метод setter для подключенной розетки, будет вызван этот setter. Однако_ этот механизм не использует кодирование ключ-значение, поэтому IBOutlet, чье имя имеет префикс с подстрочником (например, _myField), не будет установлен, если только сеттер не назван точно так же, как аутлет (например, set_myField:), что является нестандартным и грубым.

Кроме того, имейте в виду, что использование свойств типа self.myProp - это не то же самое, что обращение к переменным экземпляра. Вы отправляете сообщение, когда используете свойство, точно так же, как если бы вы использовали скобочную нотацию типа [self myProp]. Все, что делают свойства, это дают вам лаконичный синтаксис для указания геттера и сеттера в одной строке, и позволяют синтезировать их реализацию; они не замыкают механизм отправки сообщений. Если вы хотите получить доступ к переменной экземпляра напрямую, но префикс self вы должны рассматривать self как указатель, например, self->myProp, который на самом деле является доступом к полю в стиле C.

Наконец, никогда не используйте венгерскую нотацию при написании кода Cocoa и избегайте других префиксов, таких как "f" и "m_" - это отметит код как написанный кем-то, кто не "понимает", и вызовет подозрение у других разработчиков Cocoa.

В общем, следуйте советам в документе Coding Guidelines for Cocoa на сайте Apple Developer Connection, и другие разработчики смогут понять ваш код, а ваш код будет хорошо работать со всеми функциями Cocoa, использующими интроспекцию во время выполнения.

Вот как может выглядеть класс контроллера окна, используя мои соглашения:

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

Вы'видите, что я'использую переменную экземпляра, которая ссылается на Employee непосредственно в моих методах -init и -dealloc, в то время как я'использую свойство в других методах. В целом, это хорошая схема работы со свойствами: Только в инициализаторах, в -dealloc, а также в getter и setter для свойства всегда касайтесь базовой переменной экземпляра.

Комментарии (2)

Я следую за Крисом Hanson' s совет в отношении подчеркивания ivar префикс, хотя я признаю, что действительно использую underscore' s для IBOutlets также. Однако I' ve, недавно начинающий перемещение моих деклараций 'IBOutlet' к '@property' линии, согласно @mmalc' s предложение. Выгода - то, что у всех моих ivars теперь есть подчеркивание, и стандартных сеттеров KVC называют (т.е. 'setNameField':). Кроме того, выход называет don' t имеют, подчеркивает в Интерфейсном Строителе.

@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
Комментарии (1)

Вы можете использовать underbar префикс на своем ivars и все еще использовать название non-underbar Вашей недвижимости. Для синтезируемого accessors просто сделайте это:

@synthesize foo = _foo;

Это говорит компилятору синтезировать foo собственность, используя the_foo ivar.

Если Вы пишете свой собственный accessors, то Вы просто используете underbar ivar в Вашем внедрении и держите non-underbar название метода.

Комментарии (0)

Лично я следую соглашениям Cocoa об именовании, используя верблюжий регистр для функций и переменных и заглавный верблюжий регистр для имен объектов (без ведущего NS, конечно).

Я считаю, что префикс типов делает код более непрозрачным для тех, кто его не писал (поскольку все неизменно используют разные префиксы), а в современной IDE разобраться в типе не так уж и сложно.

Комментарии (0)

С введением свойств я не вижу потребности в добавлении префикса " _ " к переменным случая класса. Вы можете установить простое правило (описанный в Вашем заголовочном файле), что к любым переменным, к которым получат доступ внешние к классу, нужно получить доступ через собственность, или при помощи таможенных методов на классе, чтобы затронуть ценности. Это мне кажется намного более чистым, чем наличие имен с " _ " застрявший на фронте их. Это также правильно заключает в капсулу ценности так, чтобы Вы могли управлять, как они изменены.

Комментарии (0)

Наряду с what' s сказал здесь, убедиться прочитать документацию Какао относительно Значения ключа, Наблюдая соответствующее обозначение. Строго после этого образца поможет Вам значительно в конечном счете.

Комментарии (0)

Эндрю: на самом деле есть много разработчиков Какао кто don' t используют префиксы переменной случая вообще. It' s также чрезвычайно распространенный в мире Smalltalk (на самом деле, I' d говорят it' s почти неслыханный в Smalltalk, чтобы использовать префиксы на переменных случая).

Префиксы на переменных случая всегда казались мне C ++-ism, который был принесен на Яву и затем к C#. Так как Объективный-C мир был в основном параллелен C ++ мир, где, поскольку Ява и миры C# - преемники его, которые объяснили бы " cultural" различие Вы могли бы видеть на этом между различными компаниями разработчиков.

Комментарии (0)

Мой стиль - гибрид и действительно пережиток со дней PowerPlant:

Самые полезные префиксы, которые я использую, являются " in" и " out" для параметров функции/метода. Это помогает Вам знать то, для чего параметры сразу, и действительно помогает предотвратить конфликты между параметрами метода и переменными случая (у сколько раз есть Вы замеченный параметр " table" конфликт с переменной случая того же имени). Например:

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

Тогда я использую голое имя, например, имущественные имена и переменные:

Тогда я использую " the" как префикс для местных переменных: theTable, theURL, и т.д. Снова это помогает дифференцироваться между местным жителем и и переменные случая.

Тогда следующее моделирование PowerPlant я использую горстку других префиксов: k для констант, E для enums, g для globals и s для статики.

I' ve, используя этот стиль для чего-то как 12 лет теперь.

Комментарии (1)

В то время как я люблю использовать подчеркнуть префикс для ivars, я ненавижу письмо '@synthesize' линии из-за всего дублирования (it' s не [ОЧЕНЬ СУХОЙ] [1]). Я создал макрос, чтобы помочь сделать это и уменьшить кодовое дублирование. Таким образом, вместо:

@synthesize employee = _employee;

Я пишу это:

ddsynthesize(employee);

It' s простой макрос, используя приклеивание символа, чтобы добавить подчеркивание к правой стороне:

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

Единственный недостаток - то, что это перепутает Xcode' s инструмент рефакторинга и это won' t переименован, если Вы переименовываете собственность рефакторингом.

[1]: http://en.wikipedia.org/wiki/Don' t_repeat_yourself

Комментарии (0)

Мне не нравится использовать подчеркивание в качестве префикса для любых идентификаторов, потому что и C, и C++ резервируют определенные префиксы подчеркивания для использования реализацией.

Я считаю, что использование "self.variable" некрасиво.

В общем, я использую для переменных экземпляра неприкрашенные идентификаторы (то есть без префиксов и суффиксов). Если ваш класс настолько сложен, что вы не можете запомнить переменные экземпляра, у вас проблемы. Поэтому в вашем примере я бы использовал "rect" в качестве имени переменной экземпляра и "newRect" или "aRect" в качестве имени параметра.

Комментарии (0)