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

12

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

Я цитирую:

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

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

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

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

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

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

EngineerSpock
источник
Вы не можете выиграть все, даже когда играете в Skeet Card.
JeffO
6
Справедливости ради, претензия Джона Скита на известность не является отличным мастером кода, она хочет и может быстро и точно отвечать на вопросы C # (и он буквально написал книгу). И, возможно, никогда не спит, хотя это всего лишь слух. Его мнения по этому поводу не должно быть достаточно, и его аргументация здесь не является сильной. Это не значит, что он не прав в этом случае, я просто говорю, что ваш старший имеет право сказать «приходите ко мне с фактами и причинами, а не мнениями».
фунтовые
2
Я голосую за один класс на файл, и любые перечисления или интерфейсы, которые имеют отношение только к этому классу, должны быть внутри класса, а не только внутри файла. С другой стороны, вы должны следовать стандарту кодирования компании, независимо от того, насколько это необоснованно, потому что это часть написания хорошего кода для вашей работы .
Бобсон
2
Вы можете указать, что StyleCop как плагин для Visual Studio имеет предупреждения, если в каждом файле> 1 класса
Кевин

Ответы:

20

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

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

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

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

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

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

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

Роберт Харви
источник
5
С другой стороны, код сливается отстой. Конечно, вы можете сделать их, но почему, если вам не нужно?
Роберт Харви
4

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

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

Уайетт Барнетт
источник