Как вы организуете код C# в файлы?

Что бы вы ни делали, ПОЖАЛУЙСТА, делайте это последовательно. Я не верю, что есть какой-то один ответ (хотя есть несколько неправильных). Но просто убедитесь, что вы остаетесь верны своей форме, так как это будет ключом к тому, чтобы ваши преемники могли легко находить вещи.

В настоящее время я делаю:

• Одна сборка для производственного кода + модульные тесты
• структура каталогов имитирует пространства имен
• one type per file
  • nested types get their own file, using partial types. That is:

// ------ C.cs

public partial class C : IFoo
{
    // ...
}

// ------ C.Nested.cs
partial class C
{
    public class Nested
    {
        // ...
    }
}

Я делаю примерно так же. Один момент, в котором я не согласен:

• один тип на файл

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

Я создаю одну сборку для каждого архитектурного слоя. (WinUI.exe, BusinessWorkflow.dll, BusinessComponent.dll и т. д.

Затем по одному физическому файлу на класс.

Вот такая "вертикаль".

Пространства имен, концептуально, идут горизонтально, группируя функциональность уровня домена вместе. Все данные о клиентах помещаются в пространство имен «Клиент», например, заказы помещаются в «Accounting.AccountsPayable».

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

(Хотя я должен согласиться с вышеизложенным - постоянство жизненно важно.

Для крошечных проектов с менее чем дюжиной классов достаточно одного класса на файл.

Для корпоративных проектов у меня есть несколько проектов в решении. Они сгруппированы по назначению (бизнес-классы, интерфейсы, UI). У каждого класса есть свой файл.

Независимо от того, насколько мал тип, поместите каждый тип в отдельный файл. Исключение: вложенные классы и делегаты.

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

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

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

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

Основное практическое возражение против схемы вашего друга «все в одном огромном файле» состоит в том, что Visual Studio имеет тенденцию работать очень, очень медленно, когда пытается работать с очень длинными файлами кода.

Я предпочитаю такую ​​организацию на любом языке.

Связанные небольшие классы в своих собственных файлах.

Большие классы в своем собственном файле.

Каталоги для отдельных подпроектов.