Организация Objective C класса

[@IgorFedorchuk]

Я стараюсь держать все .m файлы до 100 строк. Максимум 150.

Хотел бы посмотреть как организовываете контроллеры. Сильно маленькие классы — это уже другая крайность. Я стараюсь, чтобы в классе было не больше 600 строк. А #pragma mark — полезная вещь.

[@NikolayJuly]

При классах в 100 строк — класс делает ничего. Большая группа классов, которые делают ничего и только друг другу передают вызовы. Для меня 450 — пока все в норме, 600 — надо рефакторить, 1000 — блин, кажется я что то пропустил… Так что в среднем классы по 400 — 500 строк и все отлично.
Ну и да #pragma mark отлично разделяет методы в списке методов в классе. Это который выпадающий список в пути файла под Tool Bar'ом

[@Holms]

Мне бы ваши проблемы.
На новой работе приходиться работать с файлами где по 70тысяч строк.

Лучше не смотреть

Visual Studio на них висит, про Resharper вообще молчу. Никто не хочет молотить это на меньшие файлы.
С трудом получилось договориться что-бы новый функционал толкали в меньшие размером файлы.

Вот так и живем :)

[@NikolayJuly]

Сочувствую. Правильный подход — пометить файл как Legacy… и постепенно пилить новый функционал. Потому то рефакторить такое… и не внести багов… нереально.

[@Holms]

так и поступаем, по крайней мере стараюсь толкать такой подход

[@Goodkat]

А теперь представьте, что эти 70000 строк — на коболе, а вместо IDE — окно терминала 20х80 символов :)

[@alkozin]

Вы меня не правильно поняли, я говорю о .m файлах, не о том что вся реализация класса должна быть 100 строк. Четыре-пять категорий по 100-150 строк, итого 400-750 строк реализации для одного класса. Разница в том чтобы вместо #pragma mark использовать категории. Опять же, посмотрите в заголовки файлов из SDK: в них много категорий.

[@greenkaktus]

Мне #pragma mark – нравится тем, что помогает при последующей автогенерации документации по коду. + дополнительно помогают при навигации через строку пути доступа xcode (но это уже вкусовщина)

#warning хороши для использования в командной работе при code review (как и //FIXME).

[@alkozin]

Попробуйте разбить реализацию на несколько файлов. Тогда в выпадающем списке будет что-то около пяти методов.

Про ворнинги писал раньше. Считаю что в проекте не должно быть ворнингов. Плюс в наших проектах ворнинги всегда трактуются как ошибки.

[@Makaveli]

а вам не кажется, что разбив на файлы вы будете искать глазами не методы и метки, а файлы?

[@alkozin]

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

[@greenkaktus]

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

[@alkozin]

Интересная идея. Думаю, даже попробую.
Сейчас я делаю ревью так:
1) Новая ветка
2) Мои комментарии в формате //TODO
3) Звонок с программистом
4) Его поправки в ветке
5) Я смотрю и мерджу ветку в дев

Ворнинги будет проще увидеть и не забыть поправить.

[@Makaveli]

Симптомами этой болезни можно назвать частое использование выпадающего списка методов или поиска по файлу (⌘F).

Не согласен с тем, что это болезнь. Это смотря кому как удобнее добраться до нужного метода. И скидывать со счетов #pragra mark я бы тоже не стал. По-моему это очень удобно — разделять методы протокола


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

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

[@alkozin]

Посмотрите мои комментарии выше. Но это только мое мнение- попробуйте, вдруг понравится )

Документирование заслуживает отдельной статьи. Не стал затрагивать эту тему намеренно.

[@AnthonyBY]

спасибо за статьи, пожалуйста продолжайте

[@alkozin]

Пожалуйста! Буду рад предложениям по темам статей.

[@kostyl]

Дефайны это зло, надо писать типизированные константы

[@mChief]

Как вы после такой разбивки на категории выполняете навигацию по файлам? Пользуетесь ли вы AppCode?

[@alkozin]

Когда работаю с одной фичей открыты только нужные папки с классами. Иногда пользуюсь фильтрами внизу панели дерева проекта.
Если нужно открыть класс использую ⇧⌘O, потом делаю ⇧⌘J. Открывается папка с классом. Вынос логики в категории это как добавление еще одного уровня вместо поиска по одному уровню. AppCode не использую, привык к Xcode. Там есть похожая фича?

[@mChief]

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

>>Там есть похожая фича?
Если вы о навигации, то скорее нет. В AppCode тоже можно перейти на нужный файл (⇧⌘O) и найти его в дереве проекта (⌥F1, 1), но получается еще больше нажатий. Зато там есть удобный(и быстро работающий) рефакторинг и возможность переносить методы в категорию.