Лучшие практики для локальных констант в target-c

Question

Я вижу много кода для объективного c, который просто # определяет локальные константы, в которых он нуждается, и затем продолжает свой веселый путь. Проблема в том, что, насколько я знаю, #defines не ограничены. Многое из этого в собственном примере кода Apple. Например, в примере 5 TableViewSuite функция drawRect в TimeZoneView.m содержит следующий блок:

#define LEFT_COLUMN_OFFSET 10
#define LEFT_COLUMN_WIDTH 130

#define MIDDLE_COLUMN_OFFSET 140
#define MIDDLE_COLUMN_WIDTH 110

#define RIGHT_COLUMN_OFFSET 270

#define UPPER_ROW_TOP 8
#define LOWER_ROW_TOP 34

#define MAIN_FONT_SIZE 18
#define MIN_MAIN_FONT_SIZE 16
#define SECONDARY_FONT_SIZE 12
#define MIN_SECONDARY_FONT_SIZE 10

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

Я полагаю, это мой вопрос:

Лучше ли определять, что вам нужно в файле, который вам нужен, и не определять его в конце? Или вы думаете, что лучше использовать статические константы для такого типа вещей? Есть ли какое-то снижение производительности при использовании статических констант, или компилятор может обрабатывать их так же эффективно, как #define?

Answer 1

#defines в файлах реализации (.m) по определению ограничены тем файлом, в котором они находятся, так как никто больше #include не является файлом .m. (Вы do хотите тщательно обдумать это в общих заголовочных файлах, где упомянутая вами проблема с областями видимости является реальной, а SO_QUESTION_2345197_NAMESPACE_YOUR_CONSTANTS_APPROPRIATELY.)

Для локальных констант в файлах реализации, о которых вы, похоже, спрашиваете, #define более эффективно компилировать, но вы не получите символы при отладке. Локальные константы имеют такое преимущество, и в некоторых случаях (строковые константы? Возможно? Зависит) предотвращают дублирование постоянных данных в двоичном файле, хотя на данный момент в мире эффективность размера и компиляции (и эффективность времени выполнения для их поиска) в основном шум, если вы не профилируете какую-то узкую петлю и не обнаружили с ней проблемы.

Answer 2

В последнее время я начал использовать методы класса для хранения констант. Я начал это как хакерство для хранения имен ключей в безбожной огромной модели Core Data. Тем не менее, он оказался довольно эффективным как в коде, так и с точки зрения создания и сопровождения базы кода. Я создаю категорию примерно так:

@interface MyClass (KeyNames)
+ (NSString *) creationDate_Key;
@end

@implementation MyClass (KeyNames)

+ (NSString *) creationDate_Key{
    return @"creationDate";
} 
@end

Тогда я использую это как:

NSString *key=[MyClass creationDate_Key];

У меня есть скрипт, который генерирует методы для меня. Приятно то, что они ограничены, унаследованы и более компактны, чем длинные. Если мне нужно много использовать ключ, как в цикле, я просто запарковываю его в локальной переменной, если эффективность становится проблемой.