C# классы в отдельных файлах?

файлы дешевы, вы не делаете никому одолжение, объединяя много классов в один файл.

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

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

У меня есть одно исключение, которое менее актуально с появлением типов делегатов Func и Action в .NET 3.5: если я определяю несколько типов делегатов в проекте, я часто связываю их вместе в файле с именем делегаты.цезий.

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

public partial class MessageDescriptor : IDescriptor<MessageDescriptorProto> {}
public partial class FileDescriptor : IDescriptor<FileDescriptorProto> {}

etc. Поместить все это в свои собственные файлы было бы немного глупо.

одна вещь, чтобы иметь в виду все это: использование ReSharper облегчает доступ к вашим классам, находятся ли они в разумно именованных файлах или нет. Это не значит, что организация их должным образом не является хорошей вещью в любом случае; это больше укрепляет представление о том, что ReSharper rocks:)

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

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

Фу.cs: / / содержит только реализацию Foo

public partial class Foo 
{
   // Foo implementation
}

Фу.Бар.cs: / / содержит только Foo.Бар реализация

public partial class Foo
{
  private class Bar
  {
    // Bar implementation
  }
}

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

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

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

общественные классы: да Частные классы: (само собой разумеется) нет

Я на самом деле предпочитаю довольно большой .cs files, 5000 lines-это довольно разумная IMO, хотя большинство моих файлов на данный момент составляют всего около 500-1000 (в C++, однако, у меня были некоторые страшные файлы). Браузер объектов / представление классов, перейдите к определению и инкрементальному поиску (- I; Спасибо за этот совет, Джефф Этвуд!), все делают поиск любого конкретного класса или метода довольно легко.

Это, вероятно, все потому, что я ужасно о закрытии незаполненных вкладок.

Это конечно сильно зависит от того, как вы работаете, но есть более чем достаточно инструментов, чтобы не нужно использовать ужасные старые 70-е годы на основе file навигация по источнику (шутка, если это не было очевидно).

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

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

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

1. "Я ненавижу прокручивать вверх и вниз" - плохая причина-современные IDE теперь либо имеют встроенную функциональность для быстрого доступа к нужному коду, либо вы можете установить расширения / плагины для этой задачи. Обозреватель решений Visual Studio делает это с помощью функции поиска, но если этого недостаточно, купите VisualAssist. VisualAssist предоставляет схему элементов в исходном файле. Не нужно прокручивать, но дважды щелкните на том, что вы хотите.

есть также код-складывание. Слишком много кода? Просто сверните его в одну линию! Проблема решена.

1. "вещи легче найти, потому что они идентифицируются по файлу" - плохая причина - Опять же, современные IDE позволяют легко найти то, что вы ищете. Просто используйте Обозреватель решений или купить VisualAssist!! Технология там, используйте ее!!

2. "легче читать/слишком много кода" - плохая причина - я не слепой. Я могу видеть. Опять же, с помощью сворачивания кода я могу легко устранить беспорядок и свернуть код, который мне не нужно видеть. Это не каменный век программирования.

3. "вы забудете, где находятся классы в больших проектах" - плохо Причина-простое решение: Обозреватель решений в Visual Studio и расширение VisualAssist.

4. "вы знаете, что в проекте, не открывая ничего" - веская причина - нет спора с этим.

5. управление версиями / слияние-хорошая причина-это на самом деле один хороший аргумент в пользу правила "один класс на исходный файл", особенно в командных проектах. Если несколько человек работают над одним проектом. Это позволяет людям видеть то, что имеет изменился, с первого взгляда. Я также вижу, как это может усложнить процессы слияния, если вы используете большие файлы с несколькими классами.

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

конечно! Почему бы и нет? Кроме частных классов глупо иметь несколько классов в одном файле.

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

в дни печатных списков исходного кода, работающих на многих сотнях страниц (подумайте о телефонной книге), "правило трех пальцев" было хорошим рабочим ограничение по сложности: если вам нужно больше трех пальцев (или скрепок для бумаги или post-its) в качестве заполнителей для понимания модуля, набор зависимостей этого модуля, вероятно, был слишком сложным. Учитывая, что почти никто больше не использует распечатанные списки исходного кода, я предлагаю, чтобы это было обновлено как "правило трех окон" - Если вам нужно открыть более трех дополнительных окон, чтобы понять код, отображаемый в другом окне, этот код, вероятно, должен быть рефакторингован.

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