Стиль: цель c и соединение токенов - PullRequest
0 голосов
/ 23 августа 2010

Это вопрос стиля:

Поскольку Apple резервирует "_" приватизацию для своих ключевых слов, я думал о чем-то вроде следующего:

#import <Cocoa/Cocoa.h>

#define _(name) pvt_##name

@interface SFMeasureViewController : NSViewController {
    @private
    NSTextField *_(label);

}

@property (retain) IBOutlet NSTextField *label;

@end


@implementation SFMeasureViewController

@synthesize label = _(label);

@end

Эточтобы помочь форсировать разницу между [self label] и использованием label, когда дело доходит до сохранения и правильной утилизации переменной.Здесь использование термина «метка» в коде возвращает ошибку, заставляя пользователя различать вызов self.label или _ (метка).

Теперь _(label) содержит еще 2 символа (shift-символов), чем _label.Есть ли другие хорошие соглашения там?vLabel?Ничто так не ясно, как _label, но поскольку оно зарезервировано, я не хочу его использовать.

Мысли, критика?Это для руководства по стилю на работе, в первую очередь для работы на C ++, когда необходимо использовать Objective-C ++.

Спасибо,

Ответы [ 2 ]

0 голосов
/ 24 августа 2010

Что ж, Apple рекомендует не использовать _ в качестве первой буквы чего-либо, особенно в именах методов. Но, как, например, переменные, они сами идут против этого принципа в своих примерах кода. Поэтому я думаю, что _... отлично подходит для этого, не делая макрос. Мне также нравятся имена свойств var и переменная резервного копирования theVar. Подробнее об этом см. Обсуждение здесь в SO.

В новой среде выполнения (т. Е. 64-разрядной на Mac, или на iPhone OS, или на симуляторе iPhone, начиная с XCode 4) вам даже не нужно явно объявлять переменную резервного экземпляра; ивар создается компилятором, когда вы @synthesize его используете, и вы не можете получить к нему доступ напрямую. Таким образом, если вы в порядке с поддержкой только этих платформ, это лучший подход.

0 голосов
/ 23 августа 2010

На самом деле, нетрудно различить label / self.label внутри модуля, поэтому я не вижу проблем в использовании одного и того же имени для свойства и поля.

...