Каков ваш предпочтительный стиль кодирования для dealloc в Objective-C?

Question

Я знаю, что дискуссии о стилях кодирования, как правило, заканчиваются катастрофой и бесконечными пламенными войнами, но это не то, что я хочу достичь. В течение последнего десятилетия я в основном видел два разных стиля кодирования для методов dealloc в Objective-C. Первым и наиболее распространенным было размещение dealloc в нижней части файла. Это также стиль, который Apple использует в шаблонах по умолчанию Xcode. Логика этого, похоже, заключается в том, что dealloc вызывается, когда приближается конец объекта, поэтому конец файла кажется приятной метафорой.

С другой стороны, пара людей, как правило, ставит dealloc непосредственно под директивами @synthesize. Это имеет два основных недостатка, на мой взгляд:

1. В верхней части файла захламляется расточной код.
2. Труднее найти основные части вашего класса, вам нужно прокрутить вниз.

Огромное преимущество, на мой взгляд, заключается в том, что у вас есть прямая визуальная связь между свойствами и соответствующим сообщением release.

Другое дело в том, что уже выпущены уже выпущенные переменные. Хотя я не думаю, что это необходимо, особенно в контексте объекта, где вся переменная получает desctructed после завершения dealloc, я также склоняюсь к нулю переменных. Я привык делать это для переменных в области функций, поэтому я просто согласен с моим стилем кодирования.

Это, как большинство моих классов выглядит следующим образом:

@implementation Bar 

@synthesize foo; 

- (void)dealloc 
{ 
    [foo release], foo = nil; 

    [super dealloc]; 
} 

// Initializers and other methods… 

я уже упоминал пару плюсов и минусов. Что вы думаете об этой теме? Какой стиль кодирования вы используете в dealloc и почему? Есть ли другие плюсы и минусы, о которых я забыл упомянуть?

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

Answer 1

Мне нравится поставить реализацию dealloc прямо под инициализаторами. Таким образом, когда я добавляю новую переменную экземпляра, я помню release это сразу после того, как я .

Кроме того, мне очень полезно использовать директиву #pragma mark, чтобы упростить просмотр файла. Поэтому я «группирую» методы init и dealloc вместе под заголовком «инициализаторы». При просмотре файла, имея эти заголовки, намного легче найти то, что вы ищете, не отвлекаясь на метод dealloc.

Это может быть скучный код, но человек важен.

Answer 2

Я положил свой dealloc наверху, только под директивами @synthesize. Это немного неуклюжий и скучный код, но очень важный код, поэтому он получает лучший биллинг. Кроме того, жизненно важно иметь возможность сравнивать свойства и ссылки.

Answer 3

- (id)init{ 
    self = [super init]; 
    if(self) { 
     someVar = [[NSMutableArray alloc] init]; 
     // something like the following shouldn't be released: 
     someString = [NSString stringWithFormat:@"ANumber: %d",10]; 
    } 
    return self; 

    - (void)dealloc{ 
     [someVar release]; someVar = nil; 
     [super dealloc]; 
    } 

это так, как я это :)

Answer 4

Не установить Ивар к нулю в dealloc, если у вас нет особых причин для. Это нецелесообразно и в лучшем случае маскирует ошибки программиста, которые вам лучше узнать, чем скрывать.

Answer 5

Я положил его на дно. Это позволяет мне просто ударить в конец и перейти к нему, когда я добавляю то, что нужно освободить. Я также не хочу, чтобы это было вокруг моих синтезаторов свойств, потому что это обманчиво. Не все, что у меня есть, обязательно имеет прикрепленный к нему синтезированный аксессуар. Черт, это даже не обязательно все в инициализаторе. Если я попытаюсь использовать ярлык таким образом, я, вероятно, испорчу его.

Answer 6

Мой заказ:

1. Синтезы и @dynamic директивы (я начал делать это на вершине когда-то в 2011 году, ранее, они были с реализациями аксессоры)
2. методов класса (+load, +initialize, +sharedFoo, другие)
3. инициализаторы
4. dealloc
5. finalize
6. Пользовательские реализации аксессоры
методы на соответствие
7. протокола, сгруппированных в соответствии с протоколом (обычно с #pragma mark директивы)
8. методы обработки уведомлений (как правило, объявленные в расширении класса вверх в верхней части)
9. Другие способы (как правило, объявленные в расширение класса на вершине)

в методе dealloc:

• Не используйте сообщения о доступе, неявные (права доступа к свойствам) или явные. Любой нечистый пользовательский аксессор может быть небезопасным для вызова частично освобожденного объекта. (То же самое касается инициализаторов.)
• Не устанавливайте ivars на nil. Объект частично освобожден; почему вы все еще отправляете сообщения? (Если вы этого не сделали, тогда ничего не смотрит на значения иваров.)
• (Если было бы целесообразно установить ivars на nil) Не злоупотребляйте оператором запятой. Выражение типа [foo release], foo = nil смешивает типы (сначала void из выражения сообщения, затем id из выражения присваивания). Это отдельные заявления; пишите их как таковые.
• 
  [super dealloc] всегда последний и всегда имеет пустую строку над ним, подчеркивая его присутствие.

Конечно, у меня также есть «Обработать предупреждения как ошибки», поэтому, если я забуду [super dealloc], я сломаю свою сборку.