EngineerSpock
@EngineerSpock

Нужно ли складывать enum, class в отдельные файлы всегда?

Всем привет.

Вот поспорили тут с нашим архитектором\тимлидом на эту тему.


Он утверждает, что разобраться в крупном проекте проще, если «объединённые логикой сущности» будут сложены в один .cs-файл.

Цитирую:
  • «всю структуру логики и интерфейсов и класса видно в одном месте, это довод который ничем не опровергнуть. что бы увидеть то же самое но с учётом разброса по файлам нужно пользоватся инструментами, class diagram, R# для навигации и др.»

  • «по голой теории я тоже могу долго подводить, что отдельный файл это круто, но когда дело доходит до внесения изменений в существующий код, особенно если не тобой написан, который раскидан по 3 файлам уже беда, а когда код раскидан на 20 и более файлов, „поубивав-бы“. Так что на форумах тоже можешь писать, что один exception — один файл, но на практике такое применять никогда не стоит»

  • "… разделение между разработчиками в текущем использовании TFS не несёт никаких проблем, можно одновременно редактировать один и тот же файл"



Везде пишут, что один enum, class — один файл — это best practice.

Ссылки можно не приводить.


А как вы считаете? Есть ли здесь реальная проблема? Или это дело вкуса и должно регулироваться стандартом кодирования в организации?
  • Вопрос задан
  • 8321 просмотр
Пригласить эксперта
Ответы на вопрос 7
@Flexz
Один класс — один файл, а в классе можно разместить и enum и другой класс. На мой взгляд повышает структурированность кода.
Любое правило возводимое в абсолют может приносить больше вреда, чем пользы.
Ответ написан
Комментировать
Illivion
@Illivion
Создаю под каждый класс, структуру, интерфейс, перечисление свой файл. Использую папки для структурирования. Сомнения возникают только с делегатами, которые уж совсем маленькие.
Ответ написан
ICELedyanoj
@ICELedyanoj
Один файл = Один класс или Struct. Иногда (очень редко) делаю исключения для нескольких Enum, но в последнее время стараюсь так не делать.
Если мне необходимо логически объединить несколько сущностей в одну кучу — создаю папку в проекте, и кидаю эти сущности в папку. Само собой namespace соответствует относительному пути.
У нас в компании тоже случаются очень горячие споры по этому поводу, поэтому точно могу сказать, что рекомендации рекомендациями, но все люди разные.
Из аргументов в защиту своего правила могу привести очень свежий пример. Сейчас разбираюсь с проектом, в который вошел только на этапе разработки второй версии и в этом проекте существовали файлы с 10+ классами внутри. Причем сами файлы иногда носили имя, которое не дает возможности однозначно понять что же находится в этом файле. Было очень трудно разобраться с архитектурой до того момента, пока постепенно не привел все к нормальной структуре с подпапками. Без этого проект полон сюрпризов — перемещаешься по нему как наощупь, не имея куда попал после очередного перехода к классу и почему.
Ответ написан
Комментировать
GavriKos
@GavriKos
Сугубое ИМХО: в большинстве случаев один класс — один файл. Энумы, используемые в этом классе — в файл самого класса. Делаю исключение только для маленьких классов-наследников. Например, если есть базовый класс, и много мелких классов-наследников (в каждом по 1-2 новых поля, классы в большинстве являются просто контейнерами) — то их складывал в один файл.
Ответ написан
@stringer
Проблема есть, но корни её тянутся не от отсюда. Попробую объяснить на примере, представим: есть файл с двумя классами в проекте на 5к строк, проект имеет историю и сменный состав программистов. С течением времени файл разросся и некто Пупкин решает разделить его. Дело нехитрое - в проект добавляется новый файл, один из классов переносится в него, commit. На этом месте история правок перенесённого класса потеряна.
Если бы каждый Пупкин мог корректно клонировать файл в репе, а потом делить с сохранением истории изменений, для облегчения понимания действительно было бы правильно связанные сущности в одно место, но в реале нам такого счастья не дано. На проект в любой момент может прийти новый персонаж, уровень компетенции наперёд непредсказуем, поэтому тактически более умным ходом считаю разделять всё по файлам. Исключение делаю только для enum и delegate объявленных совместно с интерфейсом, где они используются.
Ответ написан
Комментировать
Brand
@Brand
Более объективного, чем просто ИМХО, ждать не стоит.
Позиция такая же, почему не стоит хранить все файлы в одной папке — время на осмысливание и обработку важнее сэкономленных разбиений.
При этом если неким элементом будет пользоваться гарантированно ровно один другой элемент, есть смысл забросить их в один кусок кода.
Ответ написан
Комментировать
gouranga
@gouranga
Под каждый класс, структуру и перечисление, как и коллеги выше, делаю отдельный файл.
Правда, бывают и обратные исключения, когда класс приходится объявлять partial и реализовывать тяжелый (строк под 3000+) интерфейс отдельно.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы