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

У меня была дискуссия с нашей командой teamlead\architect на эту тему.

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

Я цитирую:

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

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

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

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

Ответ 1

По-моему:

Маленькие перечисления и классы, которые необходимы внутри большего логического класса, могут оставаться в его файле.
Но если меньшие классы и перечисления используются вне этой области, вы должны иметь их отдельно (хотя, если они логически связаны, они могут быть в одном файле). Поэтому я согласен с ним в логической связи.

Говоря это, я должен сказать, что есть другие альтернативы, вы можете создавать логические папки внутри проекта для хранения классов из одной и той же логической среды или подключений.
Сегодня IDE предоставляют вам легкий доступ и мобильность во всем решении с функциональностью Go-To, поэтому поиск кода не является проблемой.

Сохранение логических компонентов вместе (при условии, что они действительно тесно связаны) имеет большое преимущество при масштабировании. По мере того, как проект становится все больше, он, как правило, получает больше беспорядка, и это именно то, чего он пытается избежать.

Кстати, если внимательно прочитать мнение Skeet, вы заметите:

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

Ответ 2

Это очень важный вопрос, и здесь было бы лучше написано:

https://codereview.stackexchange.com/

Однако обычно вы должны размещать определения всех типов в своих файлах, за некоторыми исключениями:

Класс кодовых контрактов, используемый для предоставления контрактов для абстрактного базового класса или интерфейса, логически принадлежит этому классу.
Перечень, который используется только как параметр, свойство или возвращаемое значение внутри класса, также принадлежит этому классу (но не вложен в него).

Есть, вероятно, несколько других исключений, но обычно каждый тип должен входить в отдельный файл.

Ответ 3

Интересный вопрос, это мое занятие.

Вы должны провести различие между логической группировкой (пространством имен) и физической группировкой (файл/проект).

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

Если перечисление используется только одним типом класса, вы также можете поместить его в сам класс. Таким образом, ясно, что он принадлежит к этому конкретному классу и, как таковой, находится в одном файле кода. Если перечисление больше похоже на перечисление общего назначения, используемое в нескольких классах, затем поместите его отдельно в свой собственный файл кода.

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

Ответ 4

Я думаю, что ваше мнение "teamlead\architect" в значительной степени основано на плохом использовании пространств имен. каждый раз, когда я слышал этот аргумент от разработчика, это из-за почти полного отсутствия использования пространства имен (и тогда это становится действительно беспорядочным, если вы добавляете много файлов)

Ответ 5

Я не согласен со многими моментами, сделанными "teamlead/architect" здесь.

Как и много вещей, связанных с кодом, это вопрос мнения.

Лично я считаю, что лучше всего создать один .cs файл для каждого enum, класса и т.д. Обычно, если есть один класс, который наиболее тесно связан с перечислением, и я помещаю их в один и тот же файл.

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

Ответ 6

Вы и он можете взглянуть на большое количество сложных проектов с открытым исходным кодом в Интернете. Посмотрите на github, codeplex и подобные места.

Например, посмотрите исходный код MVC. Если класс файл достаточно хорош для Microsoft и как сложный проект MVC, я думаю, что есть хорошие шансы, что это тоже будет хорошо для вас, ребята.

Лично я использую подход класса/интерфейса для каждого файла (за исключением отдельных случаев, например, с небольшим перечислением, но с этим субъективным), и я не вижу никаких проблем с ним.