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

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

Я цитирую:

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

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

• «... Что касается разделения кодовой базы между разработчиками, в настоящее время нет проблем редактировать одновременно один и тот же файл. Слияние не является проблемой».

Я много раз слышал и читал, что нам нужно создать один файл .cs для каждого перечисления, класса и т. Д., И это лучшая практика.

Но я не могу убедить его. Он говорит, что не доверяет никаким известным программистам, таким как Джон Скит. Кстати, вот мнение Скита по этой теме: Где лучше всего найти типы перечислений?

Как вы думаете? Есть ли реальная проблема? Или это дело вкуса и должно регулироваться стандартом кодирования организации?

В аргументе вашего руководителя группы есть несколько недостатков:

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

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

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

4. Объединение объектов «логическим» способом является произвольным (то есть вы должны подумать о том, что означает «логический». Я бы скорее потратил эти такты на выполнение реального программирования).

Настройка каждого определения объекта в своем собственном файле создает единообразное, дисциплинированное ожидание организации и структуры и не вызывает вопросов типа «почему это здесь?» Это очень приятно иметь.

Если два или более объектов логически связаны, просто поместите их в свою папку в Project Explorer.

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

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