Комментарии 21
Я стараюсь держать все .m файлы до 100 строк. Максимум 150.
Хотел бы посмотреть как организовываете контроллеры. Сильно маленькие классы — это уже другая крайность. Я стараюсь, чтобы в классе было не больше 600 строк. А #pragma mark — полезная вещь.
При классах в 100 строк — класс делает ничего. Большая группа классов, которые делают ничего и только друг другу передают вызовы. Для меня 450 — пока все в норме, 600 — надо рефакторить, 1000 — блин, кажется я что то пропустил… Так что в среднем классы по 400 — 500 строк и все отлично.
Ну и да #pragma mark отлично разделяет методы в списке методов в классе. Это который выпадающий список в пути файла под Tool Bar'ом
Ну и да #pragma mark отлично разделяет методы в списке методов в классе. Это который выпадающий список в пути файла под Tool Bar'ом
Мне бы ваши проблемы.
На новой работе приходиться работать с файлами где по 70тысяч строк.
Visual Studio на них висит, про Resharper вообще молчу. Никто не хочет молотить это на меньшие файлы.
С трудом получилось договориться что-бы новый функционал толкали в меньшие размером файлы.
Вот так и живем :)
На новой работе приходиться работать с файлами где по 70тысяч строк.
Лучше не смотреть
Visual Studio на них висит, про Resharper вообще молчу. Никто не хочет молотить это на меньшие файлы.
С трудом получилось договориться что-бы новый функционал толкали в меньшие размером файлы.
Вот так и живем :)
Вы меня не правильно поняли, я говорю о .m файлах, не о том что вся реализация класса должна быть 100 строк. Четыре-пять категорий по 100-150 строк, итого 400-750 строк реализации для одного класса. Разница в том чтобы вместо #pragma mark использовать категории. Опять же, посмотрите в заголовки файлов из SDK: в них много категорий.
Мне #pragma mark – нравится тем, что помогает при последующей автогенерации документации по коду. + дополнительно помогают при навигации через строку пути доступа xcode (но это уже вкусовщина)
#warning хороши для использования в командной работе при code review (как и //FIXME).
#warning хороши для использования в командной работе при code review (как и //FIXME).
Попробуйте разбить реализацию на несколько файлов. Тогда в выпадающем списке будет что-то около пяти методов.
Про ворнинги писал раньше. Считаю что в проекте не должно быть ворнингов. Плюс в наших проектах ворнинги всегда трактуются как ошибки.
Про ворнинги писал раньше. Считаю что в проекте не должно быть ворнингов. Плюс в наших проектах ворнинги всегда трактуются как ошибки.
Симптомами этой болезни можно назвать частое использование выпадающего списка методов или поиска по файлу (⌘F).
Не согласен с тем, что это болезнь. Это смотря кому как удобнее добраться до нужного метода. И скидывать со счетов #pragra mark я бы тоже не стал. По-моему это очень удобно — разделять методы протокола
Хотя бы визуальное разделение методов на такие вот блоки в списке это уже удобно, по-моему. Лично мне помогает гораздо быстрее найти нужный метод, чем в классах, где такой организации нет.
Ну и если уж про организацию говорить, то, по-моему, стоит упомянуть о документировании кода.
спасибо за статьи, пожалуйста продолжайте
Дефайны это зло, надо писать типизированные константы
Как вы после такой разбивки на категории выполняете навигацию по файлам? Пользуетесь ли вы AppCode?
Когда работаю с одной фичей открыты только нужные папки с классами. Иногда пользуюсь фильтрами внизу панели дерева проекта.
Если нужно открыть класс использую ⇧⌘O, потом делаю ⇧⌘J. Открывается папка с классом. Вынос логики в категории это как добавление еще одного уровня вместо поиска по одному уровню. AppCode не использую, привык к Xcode. Там есть похожая фича?
Если нужно открыть класс использую ⇧⌘O, потом делаю ⇧⌘J. Открывается папка с классом. Вынос логики в категории это как добавление еще одного уровня вместо поиска по одному уровню. AppCode не использую, привык к Xcode. Там есть похожая фича?
>>Вынос логики в категории это как добавление еще одного уровня вместо поиска по одному уровню.
Вот это меня и смутило. Поиск нужного метода несколько замедляется, но возможно это не так и критично.
>>Там есть похожая фича?
Если вы о навигации, то скорее нет. В AppCode тоже можно перейти на нужный файл (⇧⌘O) и найти его в дереве проекта (⌥F1, 1), но получается еще больше нажатий. Зато там есть удобный(и быстро работающий) рефакторинг и возможность переносить методы в категорию.
Вот это меня и смутило. Поиск нужного метода несколько замедляется, но возможно это не так и критично.
>>Там есть похожая фича?
Если вы о навигации, то скорее нет. В AppCode тоже можно перейти на нужный файл (⇧⌘O) и найти его в дереве проекта (⌥F1, 1), но получается еще больше нажатий. Зато там есть удобный(и быстро работающий) рефакторинг и возможность переносить методы в категорию.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Организация Objective C класса