Cocoa Плохие привычки

Ответ 1

Передача NULL аргументам, вызывающим NSError**, чистым леним.

Ответ 2

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

Использование шаблона singleton для совместного использования объектов, например + [MyObject defaultObject]. Это, по сути, глобальная переменная, которая делает некоторые приятные скрытые зависимости и связь. Это, в свою очередь, затрудняет проверку кода.

Ответ 3

Использование исключений для потока управления

(И другие непредвиденные обстоятельства.)

Так как использование исключений приведено здесь в другом ответе, а documentation, о котором говорится в комментариях, не особо подчеркивает этот момент, следует подчеркнуть, что исключения не должны использоваться для нормального потока управления (как это обычно бывает в некоторых других средах). Исключения в Cocoa сравнительно дороги. Если вы хотите сообщить об ошибке, используйте объект NSError и архитектура обработки ошибок, предоставленную Cocoa. Не бросайте исключения.

Ответ 4

Вот некоторые из моих:

Бросание исключений без каких-либо попыток поймать их. Я начал все больше полагаться на NSError, чтобы помешать NSExceptions летать примерно как пули в фильме John Woo, но у меня все еще есть много исключительного кода.

Написание быстрого класса для выполнения X, Y и Z, а затем забывание очистить в dealloc. Утечки ahoy!

Использование строк непосредственно в разных местах (KVO) вместо определения константы и использования этого (см. Dave Dribin превосходное сообщение в блоге о KVO для более )

Ответ 5

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

self.displayName = name

в некоторых местах и ​​

displayName = name

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

Ответ 6

Я чаще использую #define, где я должен использовать объявления const.

Кроме того, я, вероятно, слишком плодовитый в NSNotifications, которые я бросаю; развязать бег amok!

Ответ 7

Плохая привычка: сохранение моего мышления.

Мой Java-фон заставляет меня одержимо проверить нуль, даже подумав о том, чтобы что-то делать с переменной, когда я мог использовать возможность Objective-C отправлять сообщение в nil. (См.: Отправка сообщения в нуль?)

Вместо того, чтобы пытаться улавливать ноль, я должен напомнить себе, что Objective-C позволяет мне просто писать код, который изящно работает с возвращаемыми значениями 0 или nil.

Ответ 8

Ты имеешь в виду, кроме самодовольства, когда я умею делать в десяти строках, что берет MFC-кодер 300? Я полагаю, что моя самая большая проблема в моем собственном коде - взрыв аксессуаров; следующая работа над проектом Я делаю, я поставил перед собой задачу использовать наименьшее количество свойств.

Ответ 9

Неправильные привязки для привязки свойств объекта модели друг к другу. Это использование Bindings приводит к тому, что трудно понять, трудно отлаживать и трудно тестировать. Используйте привязки только для привязки интерфейса к контроллеру. Если вам нужны развязанные модели, используйте NSNotification вместо привязок. По крайней мере, это немного более явный, чем KVO.

Ответ 10

Строки жесткого кодирования, такие как кнопки/заголовки. Чистый ленивый. Теперь нужно вытащить все, чтобы поддерживать локализацию: (

Ответ 11

Я научился ненавидеть интерфейс @# $% - er назад, когда он был намного менее полезен и более глючен, чем сейчас, и поэтому имеет тенденцию создавать весь мой пользовательский интерфейс в коде, стойко все же избегая IB. Это глупо, поскольку я знаю, что это снижает мою производительность на тонну, но мне просто не кажется, что мне надоело проводить дневное обучение, как подключать вещи к IB. (Да, я знаю, как делать простые вещи, но я всегда раздражаюсь, когда есть некоторые вещи, которые не очень простые, а IB, похоже, работает против меня.)

Хорошо, ты убедил меня - я собираюсь сломать ЭТО плохую привычку в эти выходные.

Спасибо!:)

Ответ 12

Это несколько общий и необязательный cocoa специфический, но:

Недостаточно рефакторинга, потому что лень обновлять файлы .m и .h.

XCode 3 упрощает некоторые виды рефакторинга, такие как переименования, но я обнаружил, что рефакторинг реже реже, чем на Java или С#, и что плохая привычка я пытаюсь сломать.

Ответ 13

1) При использовании частных глобальных переменных запустите их с символами подчеркивания и поместите их в часть интерфейса .m файла так:

@interface MyViewController (){
    NSArray *_tableData;
    NSNumberFormatter *_numberFormat;
}

2) Используйте только @properties для глобальных общедоступных переменных и/или элементов интерфейса.

3) Синтезировать глобальную публику и называть их по имени.

4) Вызовите элементы интерфейса с помощью self.labelTitle NOT _labelTitle.

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

Я реорганизую свои имена переменных LOT, и эта система облегчила мне много проблем.

Другие быстрые советы:

• Используйте раскадровку для всего, что вы можете, это облегчает проблемы с устаревшим кодом в новых версиях и значительно сокращает вашу общую базу кода.
• Назовите свои контроллеры VCMyName (контроллер просмотра), NCMyName (навигационный контроллер), TVMyName (контроллер таблицы) и т.д. Это лучше, чем стандарт Apple (MyNameViewController), потому что привязка к полному имени в конце часто отключается из-за будучи слишком длинным во множестве интерфейсов. Конструктор интерфейса правильно интерпретирует рекомендуемое соглашение об именах, вызывая представления "Мое имя".
• Изучите и используйте Core Data, а не свою собственную систему запросов SQLite для переадресации и создайте вспомогательную единицу для доступа к данным в одной или двух строках кода.
• Не помещайте весь ваш общий код приложения в AppDelegate, что на самом деле не для этого, вместо этого создайте блок AppController и используйте шаблон singleton для доступа к нему в ваших представлениях по мере необходимости.
• Следуйте Соглашение Apple о передаче данных вперед на следующий контроллер представления и используя делегаты для обработки возвращаемых данных. Это намного чище, чем где-то хранящиеся в мире данные.
• Создайте файл Constants.h(только h) для вашего проекта, в котором вы можете хранить элементы, используемые в вашем проекте, например, стандартизованные высоты строк и т.д. В этом файле должно быть только #define.
• Храните данные входа в цепочку ключей, таким образом, они более безопасны, и если они удаляют приложение и полностью его переустанавливают, он все еще существует, и вам не нужно их загружать с помощью запросов на вход.
• Сохраняйте пользовательские настройки для вашего приложения в NSUserDefaults, это выводит их из вашей базы данных, так что если у вас есть проблемы с миграцией/другими проблемами, эти данные (которые, возможно, являются единственными данными, которые вы не можете перезагрузить с нуля в своем приложении) 't затронутый.
• Вытягивать запросы из основных данных в словари, если вы передаете их в представление, это не позволяет вашим основным объектам данных выходить из ваших представлений, а также повышает производительность.
• Следуйте Apple Cocoa соглашения для имен переменных и функций. Если у вас есть сомнения, всегда смотрите, есть ли у Apple соглашение для этого.

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

Ответ 14

Мне часто приходится забывать вводить return self; часть моих конструкторов. К счастью, я начал нарушать эту особую привычку.