Какие передовые практики вы используете при написании Objective-C и Какао?

Золотое правило: если у вас alloc, то вы release!

ОБНОВЛЕНИЕ: если вы не используете ARC

Я начал делать несколько вещей, которые не считаю стандартными:

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

2) Говоря о частных вещах, я предпочитаю размещать определения частных методов в файле .m в расширении класса, например:

#import "MyClass.h"

@interface MyClass ()
- (void) someMethod;
- (void) someOtherMethod;
@end

@implementation MyClass

Зачем загромождать файл .h вещами, которые не должны волновать посторонних? Пустой () работает для частных категорий в файле .m и выдает предупреждения компиляции, если вы не реализуете объявленные методы.

3) Я решил поместить dealloc в начало файла .m, чуть ниже директив @synthesize. Разве то, что вы освобождаете, не должно быть в верхней части списка вещей, о которых вы хотите думать в классе? Это особенно актуально в среде, подобной iPhone.

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

3.6) При использовании NSURLConnection, как правило, вы можете захотеть реализовать метод делегата:

- (NSCachedURLResponse *)connection:(NSURLConnection *)connection
                  willCacheResponse:(NSCachedURLResponse *)cachedResponse
{
      return nil;
}

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

Также интересны несколько хороших советов по iPhone от Джозефа Маттиелло (полученные в списке рассылки iPhone). Есть и другие, но они были наиболее полезными, как я думал (обратите внимание, что несколько фрагментов были немного отредактированы по сравнению с оригиналом, чтобы включить детали, предлагаемые в ответах):

4) Используйте двойную точность только в случае необходимости, например, при работе с CoreLocation. Убедитесь, что вы заканчиваете свои константы на 'f', чтобы gcc сохранял их как числа с плавающей запятой.

float val = someFloat * 2.2f;

Это особенно важно, когда someFloat может фактически быть двойным, вам не нужна математика в смешанном режиме, поскольку вы теряете точность в 'val' при хранении. Хотя числа с плавающей запятой аппаратно поддерживаются на iPhone, для выполнения арифметических операций с двойной точностью может потребоваться больше времени, чем для арифметических операций с одинарной точностью. Использованная литература:

• Double vs float на iPhone
• Математика двойной точности для iPhone / iPad

На старых телефонах предположительно вычисления выполняются с той же скоростью, но в регистрах может быть больше компонентов одинарной точности, чем удвоений, поэтому для многих вычислений одинарная точность будет быстрее.

5) Установите свои свойства как nonatomic. По умолчанию это atomic, и после синтеза будет создан семафорный код для предотвращения проблем с многопоточностью. 99% из вас, вероятно, не должны беспокоиться об этом, и код намного менее раздут и более эффективен с точки зрения памяти, когда установлен неатомарный.

6) SQLite может быть очень и очень быстрым способом кэширования больших наборов данных. Например, картографическое приложение может кэшировать свои листы в файлы SQLite. Самая дорогая часть - это дисковый ввод-вывод. Избегайте множества мелких записей, отправляя BEGIN; и COMMIT; между большими блоками. Например, мы используем 2-секундный таймер, который сбрасывается при каждой новой отправке. Когда он истекает, мы отправляем COMMIT; , что приводит к тому, что все ваши записи идут одним большим фрагментом. SQLite хранит данные транзакции на диске, и выполнение этой упаковки «Начало / конец» позволяет избежать создания множества файлов транзакций, группируя все транзакции в один файл.

Кроме того, SQL заблокирует ваш графический интерфейс, если он находится в вашем основном потоке. Если у вас очень длинный запрос, рекомендуется хранить запросы как статические объекты и запускать SQL в отдельном потоке. Обязательно оберните все, что изменяет базу данных для строк запроса, в блоки @synchronize() {}. Для коротких запросов просто оставьте все в основном потоке для большего удобства.

Здесь можно найти больше советов по оптимизации SQLite, хотя документ кажется устаревшим, многие пункты, вероятно, все еще хороши;

http://web.utk.edu/~jplyon/sqlite/SQLite_optimization_FAQ.html

@kendell

Вместо:

@interface MyClass (private)
- (void) someMethod
- (void) someOtherMethod
@end

Использовать:

@interface MyClass ()
- (void) someMethod
- (void) someOtherMethod
@end

Новое в Objective-C 2.0.

Расширения классов описаны в Apple Objective-C 2.0 Reference.

«Расширения класса позволяют объявлять дополнительный требуемый API для класса в местах, отличных от основного блока @interface class»

Таким образом, они являются частью фактического класса, а НЕ (частной) категорией в дополнение к классу. Тонкая, но важная разница.

Очистите в dealloc.

Об этом легче всего забыть - особенно. при кодировании на скорости 150 миль в час. Всегда, всегда, всегда очищайте свои атрибуты / переменные-члены в dealloc.

Мне нравится использовать атрибуты Objc 2 - с - новую точечную нотацию, так что это делает очистку безболезненной. Часто бывает так просто, как:

- (void)dealloc
{
    self.someAttribute = NULL;
    [super dealloc];
}

Это позаботится о выпуске за вас и установит для атрибута значение NULL (что я считаю защитным программированием - в случае, если другой метод, расположенный ниже в dealloc, снова обращается к переменной-члену - редко, но происходит мог).

Когда сборщик мусора включен в 10.5, в этом больше нет необходимости, но вам все равно может потребоваться очистка других ресурсов, которые вы создаете, вы можете сделать это в методе finalize.

Это тонкий, но удобный. Если вы передаете себя в качестве делегата другому объекту, сбросьте делегата этого объекта перед dealloc.

- (void)dealloc
{
self.someObject.delegate = NULL;
self.someObject = NULL;
//
[super dealloc];
}

Делая это, вы гарантируете, что больше не будут отправлены методы делегата. Когда вы приближаетесь к dealloc и исчезаете в эфире, вы хотите убедиться, что ничто не сможет отправить вам больше сообщений случайно. Помните, что self.someObject может быть сохранен другим объектом (это может быть одноэлементный объект или в пуле автозапуска, или что-то еще), и пока вы не скажете ему «перестань отправлять мне сообщения!», Он будет думать, что ваш объект, который вот-вот должен быть освобожден это честная игра.

Привыкание к этой привычке избавит вас от множества странных сбоев, отлаживать которые сложно.

Тот же принцип применяется и к наблюдению за ключевыми значениями, и к NSNotifications.

Редактировать:

Еще более оборонительное изменение:

self.someObject.delegate = NULL;

в:

if (self.someObject.delegate == self)
    self.someObject.delegate = NULL;

Старайтесь избегать того, что я сейчас назвал категорией для новичков. Когда новички в Objective-C открывают для себя категории, они часто сходят с ума, добавляя полезные маленькие категории к каждому существующему классу («Что? Я могу добавить метод преобразования числа в римские цифры в NSNumber rock on!»).

Не делай этого.

Ваш код будет более переносимым и понятным без десятков небольших методов категорий, добавленных поверх двух десятков базовых классов.

В большинстве случаев, когда вы действительно думаете, что вам нужен метод категории, чтобы упростить некоторый код, вы обнаружите, что никогда не будете использовать этот метод повторно.

Есть и другие опасности, если вы не назначаете пространство имен для своих методов категорий (и кто, кроме совершенно безумного ddribin?), Есть вероятность, что Apple, или плагин, или что-то еще, работающее в вашем адресном пространстве, также определит ту же категорию метод с тем же именем с немного другим побочным эффектом ....

В ПОРЯДКЕ. Теперь, когда вас предупредили, игнорируйте «не делайте этого». Но проявляйте крайнюю сдержанность.

Кроме того, наполовину связанная тема (с возможностью для большего количества ответов!):

Что это за маленькие советы и хитрости Xcode, о которых вы хотели бы знать 2 года назад?.

Напишите модульные тесты. Вы можете протестировать много вещей в Какао, что может быть сложнее в других фреймворках. Например, с помощью кода пользовательского интерфейса вы обычно можете проверить, что все подключено так, как должно быть, и поверить, что они будут работать при использовании. И вы можете легко настроить состояние и вызвать методы делегата для их тестирования.

У вас также нет видимости публичных, защищенных и частных методов, которые мешают написанию тестов для ваших внутренних компонентов.

Сопротивляйтесь разделению мира на подклассы. В Какао многое делается посредством делегирования и использования базовой среды выполнения, что в других фреймворках выполняется через создание подклассов.

Например, в Java вы часто используете экземпляры анонимных подклассов *Listener, а в .NET вы часто используете свои подклассы EventArgs. В Какао вы этого не делаете - вместо этого используется target-action.

Не пишите Objective-C, как если бы это были Java / C# / C++ / и т. д.

Однажды я видел, как команда разработчиков веб-приложений Java EE пыталась написать настольное приложение Cocoa. Как будто это веб-приложение Java EE. Было много AbstractFooFactory, FooFactory, IFoo и Foo, когда все, что им действительно нужно, это класс Foo и, возможно, протокол Fooable.

Отчасти гарантировать, что вы этого не сделаете, - это истинное понимание различий в языке. Например, вам не нужны абстрактные фабричные и фабричные классы, указанные выше, потому что методы класса Objective-C отправляются так же динамически, как и методы экземпляра, и могут быть переопределены в подклассах.

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

Примеры того, что делать и чего не делать:

• Не объявляйте id m_something; в интерфейсе объекта и называйте его переменная-член или поле; используйте something или _something в качестве имени и назовите его переменная экземпляра.
• Не называйте получателя -getSomething; правильное имя Какао - просто -something.
• Не называйте сеттер -something:; это должно быть -setSomething:
• Имя метода перемежается с аргументами и включает двоеточия; это -[NSObject performSelector:withObject:], а не NSObject::performSelector.
• Используйте заглавные буквы (CamelCase) в именах методов, параметров, переменных, именах классов и т. д., А не подчеркивания (подчеркивания).
• Имена классов начинаются с верхнего регистра, имена переменных и методов - с нижнего регистра.

Что бы вы ни делали, не использует венгерскую нотацию в стиле Win16 / Win32. Даже Microsoft отказалась от этого с переходом на платформу .NET.

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

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

Убедитесь, что вы добавили в закладки страницу Отладка Magic. Это должно быть вашей первой остановкой, когда вы бьетесь головой о стену, пытаясь найти источник ошибки какао.

Например, он расскажет вам, как найти метод, в котором вы сначала выделили память, которая позже вызывает сбои (например, при завершении работы приложения).

Если вы используете Leopard (Mac OS X 10.5) или новее, вы можете использовать приложение «Инструменты» для поиска и отслеживания утечек памяти. После создания программы в Xcode выберите «Выполнить»> «Начать с инструментом производительности»> «Утечки».

Даже если ваше приложение не обнаруживает утечек, возможно, вы слишком долго храните объекты. В инструментах для этого можно использовать инструмент ObjectAlloc. Выберите инструмент ObjectAlloc в документе «Инструменты» и откройте подробные сведения об инструменте (если он еще не отображается), выбрав «Просмотр»> «Сведения» (рядом с ним должна быть галочка). В разделе «Срок службы размещения» на детали ObjectAlloc убедитесь, что вы выбрали переключатель рядом с «Создано и еще жив».

Теперь, когда вы прекращаете запись своего приложения, выбор инструмента ObjectAlloc покажет вам, сколько ссылок есть на каждый все еще живущий объект в вашем приложении, в столбце «# Net». Убедитесь, что вы смотрите не только на свои собственные классы, но и на классы объектов верхнего уровня ваших файлов NIB. Например, если у вас нет окон на экране, и вы видите ссылки на все еще живое NSWindow, возможно, вы не выпустили его в своем коде.

Не забывайте, что NSWindowController и NSViewController будут освобождать объекты верхнего уровня файлов NIB, которыми они управляют.

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

IBOutlets

Исторически сложилось так, что управление памятью розеток было плохим. Текущая лучшая практика - объявлять выходы как свойства:

@interface MyClass :NSObject {
    NSTextField *textField;
}
@property (nonatomic, retain) IBOutlet NSTextField *textField;
@end

Использование свойств проясняет семантику управления памятью; он также обеспечивает согласованный шаблон, если вы используете синтез переменных экземпляра.

Заявленные свойства

Обычно вы должны использовать функцию объявленных свойств Objective-C 2.0 для всех своих свойств. Если они не являются общедоступными, добавьте их в расширение класса. Использование объявленных свойств сразу делает семантику управления памятью и упрощает проверку вашего метода dealloc - если вы группируете объявления свойств вместе, вы можете быстро сканировать их и сравнивать с реализацией вашего метода dealloc.

Вам следует хорошенько подумать, прежде чем не отмечать свойства как «неатомные». Как отмечает Руководство по языку программирования Objective C, свойства по умолчанию являются атомарными и влекут за собой значительные накладные расходы. Более того, простая атомарность всех ваших свойств не делает ваше приложение поточно-ориентированным. Также обратите внимание, конечно, что если вы не укажете «неатомарный» и реализуете свои собственные методы доступа (а не синтезируете их), вы должны реализовать их атомарным способом.

Используйте статический анализатор LLVM / Clang

ПРИМЕЧАНИЕ. В Xcode 4 это теперь встроено в IDE.

Вы используете Статический анализатор Clang, что неудивительно, чтобы проанализировать свой код C и Objective-C (еще не C++) в Mac OS X 10.5. Установить и использовать несложно:

1. Загрузите последнюю версию с сайта эта страница.
2. Из командной строки cd в каталог вашего проекта.
3. Выполните scan-build -k -V xcodebuild.

(Есть некоторые дополнительные ограничения и т. д., В частности, вам следует проанализировать проект в его конфигурации «Отладка» - см. http://clang.llvm.org/StaticAnalysisUsage.html для подробностей - но это более или менее то, к чему он сводится.)

Затем анализатор создает для вас набор веб-страниц, которые показывают вероятное управление памятью и другие основные проблемы, которые компилятор не может обнаружить.

Не используйте неизвестные строки в качестве строк формата

Когда методы или функции принимают аргумент строки формата, вы должны убедиться, что у вас есть контроль над содержимым строки формата.

Например, при регистрации строк возникает соблазн передать строковую переменную в качестве единственного аргумента NSLog:

    NSString *aString = // get a string from somewhere;
    NSLog(aString);

Проблема в том, что строка может содержать символы, которые интерпретируются как строки формата. Это может привести к ошибочному выводу, сбоям и проблемам с безопасностью. Вместо этого следует подставить строковую переменную в строку формата:

    NSLog(@"%@", aString);

Сортировка строк по желанию пользователя

При сортировке строк для представления пользователю не следует использовать простой метод compare:. Вместо этого вы всегда должны использовать локализованные методы сравнения, такие как localizedCompare: или localizedCaseInsensitiveCompare:.

Подробнее см. Поиск, сравнение и сортировка строк.

Избегайте автоматического выпуска

Поскольку вы обычно (1) не имеете прямого контроля над их жизненным циклом, автоматически выпущенные объекты могут сохраняться в течение сравнительно долгого времени и излишне увеличивать объем памяти, занимаемый вашим приложением. Хотя на настольных компьютерах это может иметь незначительные последствия, на более ограниченных платформах это может стать серьезной проблемой. Поэтому на всех платформах, и особенно на платформах с более ограниченными возможностями, рекомендуется избегать использования методов, которые могут привести к автоматическому выпуску объектов, и вместо этого рекомендуется использовать шаблон alloc / init.

Таким образом, а не:

aVariable = [AClass convenienceMethod];

где возможно, вместо этого следует использовать:

aVariable = [[AClass alloc] init];
// do things with aVariable
[aVariable release];

Когда вы пишете свои собственные методы, которые возвращают вновь созданный объект, вы можете воспользоваться Соглашение об именах какао, чтобы указать получателю, что он должен быть освобожден, добавив к имени метода слово «новый».

Таким образом, вместо:

- (MyClass *)convenienceMethod {
    MyClass *instance = [[[self alloc] init] autorelease];
    // configure instance
    return instance;
}

можно было написать:

- (MyClass *)newInstance {
    MyClass *instance = [[self alloc] init];
    // configure instance
    return instance;
}

Поскольку имя метода начинается с «new», потребители вашего API знают, что они несут ответственность за освобождение полученного объекта (см., Например, Метод newObject NSObjectController).

(1) Вы можете взять под контроль свои собственные локальные пулы с автоматическим выпуском. Подробнее об этом см. Пулы с автоматическим выпуском.

Подумайте о нулевых значениях

Как отмечает этот вопрос, сообщения для nil действительны в Objective-C. Хотя это часто является преимуществом, приводящим к более чистому и естественному коду, эта функция может иногда приводить к специфическим и трудным для отслеживания ошибкам, если вы получаете значение nil, которого не ожидали.

Некоторые из них уже упоминались, но вот то, что я могу придумать в своей голове:

• Соблюдайте правила именования KVO. Даже если вы не используете KVO сейчас, по моему опыту, часто это все равно полезно в будущем. И если вы используете KVO или привязки, вам нужно знать, что все работает так, как должно. Это касается не только методов доступа и переменных экземпляра, но и отношений ко многим, проверки, зависимых ключей с автоматическим уведомлением и т. д.
• Поместите частные методы в категорию. Не только интерфейс, но и реализация. Концептуально хорошо иметь некоторую дистанцию ​​между частными и не частными методами. Я все включаю в свой .m файл.
• Поместите фоновые методы потока в категорию. То же, что и выше. Я обнаружил, что хорошо сохранять четкий концептуальный барьер, когда вы думаете о том, что находится в основном потоке, а что нет.
• Используйте #pragma mark [section]. Обычно я группирую по своим собственным методам, переопределениям каждого подкласса и любой информации или формальным протоколам. Это значительно упрощает переход к тому, что я ищу. По той же теме группируйте похожие методы (например, методы делегата табличного представления) вместе, а не просто прикрепляйте их куда-нибудь.
• Префикс приватных методов и ivars с _. Мне нравится, как это выглядит, и я реже использую ivar, когда имею в виду свойство случайно.
• Не используйте методы / свойства мутатора в init и dealloc. У меня никогда не случалось ничего плохого из-за этого, но я могу понять логику, если вы измените метод, чтобы сделать что-то, что зависит от состояния вашего объекта.
• Поместите IBOutlets в свойства. Я только что прочитал это здесь, но я собираюсь начать это делать. Независимо от каких-либо преимуществ памяти, стилистически это кажется лучше (по крайней мере, мне).
• Избегайте написания кода, который вам абсолютно не нужен. Это действительно касается многих вещей, таких как создание ivars, когда подойдет #define, или кеширование массива вместо его сортировки каждый раз, когда требуются данные. Я могу многое сказать по этому поводу, но главное - не пишите код, пока он вам не понадобится или пока профилировщик не скажет вам об этом. Это значительно упрощает обслуживание в долгосрочной перспективе.
• Закончите то, что начали. Наличие большого количества незаконченного кода с ошибками - это самый быстрый способ убить проект. Если вам нужен метод-заглушка, который подходит, просто укажите его, поместив NSLog( @"stub" ) внутрь, или как вы хотите отслеживать вещи.

Все эти комментарии великолепны, но я очень удивлен, что никто не упомянул Руководство по стилю Google Objective-C, который был опубликован некоторое время назад. Я считаю, что они проделали очень основательную работу.

Используйте NSAssert и друзей. Я все время использую nil как допустимый объект ... особенно отправка сообщений на nil совершенно допустима в Obj-C. Однако, если я действительно хочу убедиться в состоянии переменной, я использую NSAssert и NSParameterAssert, которые помогают легко отслеживать проблемы.

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

Включите все предупреждения GCC, затем отключите те, которые регулярно вызываются заголовками Apple, чтобы уменьшить шум.

Также часто запускайте статический анализ Clang; вы можете включить его для всех сборок с помощью параметра сборки «Запуск статического анализатора».

Напишите модульные тесты и запускайте их с каждой сборкой.

Один довольно очевидный для новичка: используйте функцию автоматического отступа Xcode для своего кода. Даже если вы копируете / вставляете из другого источника, после того, как вы вставили код, вы можете выбрать весь блок кода, щелкнуть его правой кнопкой мыши и затем выбрать вариант повторного отступа всего в этом блоке.

Xcode фактически проанализирует этот раздел и сделает отступ на основе скобок, циклов и т. д. Это намного эффективнее, чем нажатие клавиши пробела или табуляции для каждой строки.

Простой, но о котором часто забывают. Согласно спецификации:

In general, methods in different classes that have the same selector (the same name) must also share the same return and argument types. This constraint is imposed by the compiler to allow dynamic binding.

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

@interface FooInt:NSObject{}
-(int) print;
@end

@implementation FooInt
-(int) print{
    return 5;
}
@end

@interface FooFloat:NSObject{}
-(float) print;
@end

@implementation FooFloat
-(float) print{
    return 3.3;
}
@end

int main (int argc, const char * argv[]) {

    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];    
    id f1=[[FooFloat alloc]init];
    //prints 0, runtime considers [f1 print] to return int, as f1's type is "id" and FooInt precedes FooBar
    NSLog(@"%f",[f1 print]);

    FooFloat* f2=[[FooFloat alloc]init];
    //prints 3.3 expectedly as the static type is FooFloat
    NSLog(@"%f",[f2 print]);

    [f1 release];
    [f2 release]
    [pool drain];

    return 0;
}   

Будьте более функциональный.

Objective-C - объектно-ориентированный язык, но он поддерживает функциональный стиль фреймворка Какао и во многих случаях разрабатывается в функциональном стиле.

1. Есть разделение изменчивости. Используйте классы неизменный в качестве первичных, а изменяемый объект в качестве вторичных. Например, используйте в первую очередь NSArray и используйте NSMutableArray только тогда, когда вам нужно.

2. Есть чистые функции. Не так много, покупайте многие API-интерфейсы фреймворка, разработанные как чистые функции. Посмотрите на такие функции, как CGRectMake() или CGAffineTransformMake(). Очевидно, форма указателя выглядит более эффективной. Однако косвенный аргумент с указателями не может обеспечить отсутствие побочных эффектов. Проектируйте конструкции максимально чисто. Разделяйте даже государственные объекты. Используйте -copy вместо -retain при передаче значения другому объекту. Потому что общее состояние может незаметно влиять на изменение значения в другом объекте. Так что не может быть без побочных эффектов. Если у вас есть значение из внешнего объекта, скопируйте его. Так что также важно разработать как можно более минимальное общее состояние.

Однако не бойтесь использовать и нечистые функции.

1. Есть ленивая оценка. Посмотрите что-то вроде свойства -[UIViewController view]. Представление не будет создано при создании объекта. Он будет создан при первом чтении свойства view вызывающим абонентом. UIImage не будет загружен, пока он не будет отрисован. Есть много реализаций, подобных этому дизайну. Такие конструкции очень полезны для управления ресурсами, но если вы не знакомы с концепцией ленивой оценки, понять их поведение непросто.

2. Есть закрытие. По возможности используйте C-блоки. Это значительно упростит вам жизнь. Но прежде чем использовать его, прочтите еще раз об управлении блочной памятью.

3. Есть полуавтоматический GC. NSAutoreleasePool. Используйте первичный -autorelease. Используйте ручной -retain/-release вторичный, когда вам действительно нужно. (например: оптимизация памяти, явное удаление ресурсов)

Освободите только имущество в методе освободить. Если вы хотите освободить память, которую удерживает имущество, просто установите ее как nil:

self.<property> = nil;

Переменные и свойства

1 / Сохранение чистоты заголовков, скрытие реализации
Не включайте переменные экземпляра в заголовок. Частные переменные помещаются в продолжение класса как свойства. Публичные переменные объявляются в вашем заголовке как общедоступные свойства. Если он должен быть только для чтения, объявите его как доступный только для чтения и перезапишите его как readwrite в продолжении класса. В основном я вообще не использую переменные, а только свойства.

2 / Дайте вашим свойствам имя переменной, отличное от имени переменной по умолчанию, например:

@synthesize property = property_;

Причина 1: вы обнаружите ошибки, вызванные забыванием «я». при передаче собственности. Причина 2: Судя по моим экспериментам, у Leak Analyzer in Instruments есть проблемы с обнаружением утечки с именем по умолчанию.

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

Взгляды

1 / Поместите каждое определение представления в xib, если можете (исключение обычно составляет динамический контент и настройки уровня). Это экономит время (это проще, чем писать код), его легко изменить, и он сохраняет ваш код чистым.

2 / Не пытайтесь оптимизировать просмотры, уменьшая количество просмотров. Не создавайте UIImageView в своем коде вместо xib только потому, что вы хотите добавить в него подпредставления. Вместо этого используйте UIImageView в качестве фона. Фреймворк представления может без проблем обрабатывать сотни представлений.

3 / IBOutlets не обязательно всегда сохранять (или быть сильными). Обратите внимание, что большинство ваших IBOutlet являются частью вашей иерархии представлений и поэтому неявно сохраняются.

4 / Освободить все IBOutlets в viewDidUnload

5 / Вызовите viewDidUnload из вашего метода dealloc. Это не вызывается неявно.

объем памяти

1 / Автозапуск объектов при их создании. Многие ошибки вызваны перемещением вашего релизного вызова в одну ветку if-else или после оператора return. Release вместо autorelease следует использовать только в исключительных ситуациях - например, когда вы ждете выполнения цикла выполнения и не хотите, чтобы ваш объект был автоматически выпущен слишком рано.

2 / Даже если вы используете автоматический подсчет ссылок, вы должны хорошо понимать, как работают методы сохранения-освобождения. Использование удержания-выпуска вручную не сложнее, чем ARC, в обоих случаях вам нужно подумать об утечках и циклах удержания. Рассмотрите возможность использования сохранения-выпуска вручную для больших проектов или сложных иерархий объектов.

Комментарии

1 / Сделайте свой код автодокументированным. Каждое имя переменной и имя метода должны указывать на то, что они делают. Если код написан правильно (в этом вам потребуется много практики), вам не понадобятся комментарии к коду (не то же самое, что комментарии к документации). Алгоритмы могут быть сложными, но код всегда должен быть простым.

2 / Иногда вам понадобится комментарий. Обычно для описания неявного поведения кода или взлома. Если вы чувствуете, что должны написать комментарий, сначала попробуйте переписать код, чтобы он был проще и без комментариев.

Отступ

1 / Не увеличивайте слишком много отступов. Большая часть кода вашего метода должна иметь отступ на уровне метода. Вложенные блоки (if, for и т. д.) Ухудшают читаемость. Если у вас есть три вложенных блока, вы должны попытаться поместить внутренние блоки в отдельный метод. Ни в коем случае нельзя использовать четыре или более вложенных блока. Если большая часть кода вашего метода находится внутри if, отмените условие if, например:

if (self) {
   //... long initialization code ...
}

return self;

if (!self) {
   return nil;
}

//... long initialization code ...

return self;

Понять C-код, в основном C-структуры

Обратите внимание, что Obj-C - это только легкий слой ООП над языком C. Вы должны понимать, как работают базовые структуры кода в C (перечисления, структуры, массивы, указатели и т. д.). Пример:

view.frame = CGRectMake(view.frame.origin.x, view.frame.origin.y, view.frame.size.width, view.frame.size.height + 20);

такой же как:

CGRect frame = view.frame;
frame.size.height += 20;
view.frame = frame;

И многое другое

Поддерживайте свой собственный документ стандартов кодирования и часто обновляйте его. Постарайтесь учиться на своих ошибках. Разберитесь, почему была создана ошибка, и постарайтесь избежать ее, используя стандарты кодирования.

Наши стандарты кодирования в настоящее время включают около 20 страниц, смесь стандартов кодирования Java, стандартов Google Obj-C / C++ и наших собственных дополнений. Задокументируйте свой код, используйте стандартные стандартные отступы, пробелы и пустые строки в нужных местах и ​​т. Д.

#import "MyClass.h"

@interface MyClass ()
- (void) someMethod;
- (void) someOtherMethod;
@end

@implementation MyClass