Должны ли папки в решении соответствовать пространству имен?

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

Классы будет легче найти, и это само по себе должно быть достаточно веской причиной.

Правила, которым мы следуем, таковы:

• Имя Project/assembly совпадает с именем корневого пространства имен, за исключением окончания .dll
• Единственным исключением из вышеприведенного правила является проект с окончанием .Core, при этом .Core снимается
• Папки равны пространствам имен
• Один тип на файл (класс, структура, перечисление, делегат и т. д.) позволяет легко найти нужный файл

№

Я пробовал оба метода на небольших и больших проектах, как с одним (мной), так и с командой разработчиков.

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

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

Возьмем, например, это предупреждение FxCop:

CA1020: избегайте пространств имен с несколькими типами
причина: пространство имен, отличное от глобального пространства имен, содержит менее пяти типов https://msdn.microsoft.com/en-gb/library/ms182130.aspx

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

Поиск Файлов

Принятый ответ гласит: "классы будет легче найти, и это само по себе должно быть достаточно веской причиной."

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

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

Столкновения имен

Конечно, создание нескольких пространств имен позволяет проекту иметь два класса с одинаковым именем. Но разве это действительно хорошо? Может быть, проще просто запретить это быть возможным? Разрешение двух классов с одинаковым именем создает более сложную ситуацию, когда 90% из них работают определенным образом, а затем внезапно вы обнаруживаете, что у вас есть особый случай. Допустим, у вас есть два класса прямоугольников, определенных в разных пространствах имен:

• класс Project1.Image.Rectangle
• класс Project1.Window.Rectangle

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

var rectangle = new Project1.Window.Rectangle();

Или возиться с каким-нибудь неприятным оператором using:

using Rectangle = Project1.Window.Rectangle;

С одним пространством имен в вашем проекте вы вынуждены придумывать разные, и я бы сказал более описательные, имена, подобные этому:

• класс Project1.ImageRectangle
• класс Project1.WindowRectangle

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

оператор using

using Project1.General;  
using Project1.Image;  
using Project1.Window;  
using Project1.Window.Controls;  
using Project1.Shapes;  
using Project1.Input;  
using Project1.Data;  

против

using Project1;

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

Изменение структуры папок проекта

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

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

Visual Studio автоматически сопоставляет пространство имен нового файла с папкой проекта, в которой он был создан

К сожалению, но я нахожу, что хлопот по исправлению пространства имен меньше, чем хлопот по их устранению. Кроме того, у меня вошло в привычку копировать вставку существующего файла, а не использовать Add->New.

Intellisense и обозреватель объектов

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

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

Я думаю, что стандарт, в пределах .NET, заключается в том, чтобы попытаться сделать это, когда это возможно, но не создавать излишне глубокие структуры, просто придерживаться его как жесткого правила. Ни один из моих проектов не следует правилу namespace = = structure 100% того времени, иногда его просто чище/лучше вырваться из таких правил.

В Java году у вас нет выбора. Я бы назвал это классическим случаем того, что работает в теории против того, что работает на практике.

@lassevk: я согласен с этими правилами и хочу добавить еще одно.

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

// ----- Foo.cs
partial class Foo
{
    // Foo implementation here
}

и

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}

Я бы сказал, что да.

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

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

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

Да, они должны, только приводит к путанице в противном случае.

А каков стандарт?

Официального стандарта нет, но обычно наиболее широко используется шаблон отображения folder-to-namespace.

В библиотеках классов папки обычно совпадают с пространством имен структура или это смешанный мешок?

Да, в большинстве библиотек классов папки соответствуют пространству имен для удобства организации.