Должен ли я прекратить борьбу с соглашением об именах имен пространства имен Visual Studio по умолчанию?

Я работаю над проектом MVVM, поэтому у меня есть папки в моем проекте, такие как Models, ViewModels, Windows и т.д. Всякий раз, когда я создаю новый класс, Visual Studio автоматически добавляет имя папки в обозначение пространства имен, а не просто сохраняет пространство имен на уровне проекта. Таким образом, добавление нового класса в папку ViewModels приведет к пространству имен MyProject.ViewModels вместо просто MyProject.

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

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

Вопросы:

Почему это общее соглашение для имен пространства имен отражает структуру папок?
Вы придерживаетесь этой конвенции? Почему?

Ответ 1

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

Например, в проекте MVVM может оказаться полезным разместить представления и просмотреть модели в отдельном пространстве имен. MVC будет иметь отдельное пространство имен для моделей, контроллеров и представлений. Также полезно группировать классы по их признаку.

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

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

Ответ 2

Если вы хотите получить солидный совет, я бы рекомендовал купить Framework Design Guidelines: условные обозначения, идиомы и шаблоны для многоразовых .NET-библиотек, который дает вам все, что вам нужно знать, от фактической команды разработки рамок.

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

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

И что важно

Не использовать одно и то же имя для пространства имен и типа в этом пространстве имен

Фрагментирование каждых 1/2 типов в пространства имён не соответствовало бы первому требованию, поскольку у вас было бы болото пространств имен, которое должно было бы быть квалифицированным или использованным, если бы вы следовали за способом Visual Studio. Например

Основные - Домен - Пользователи - Разрешения - Учетные записи

Создаете ли вы

MyCompany.Core.Domain.Users
MyCompany.Core.Domain.Permissions
MyCompany.Core.Domain.Accounts

или просто

MyCompany.Core.Domain

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

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

Ответ 3

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

Кроме того, если ReSharper рекомендует его, то это, вероятно, хорошая идея. Например. R # будет жаловаться, если пространство имен вашего класса не соответствует имени своей папки.

Ответ 4

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

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

Ответ 5

Один из способов не следовать соглашению - создать файл в корневой папке проекта, а затем переместить его в конечную подпапку.

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

Ответ 6

Пока я согласен со всеми, что физическая структура, соответствующая логической структуре, полезна, я должен сказать, что я также сражаюсь с автоименованием Visual Studio. Есть полдюжины причин, по которым мне нужно переименовывать классы:

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

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

Ответ 7

До того как пространства имен были введены в С++, все типы C были в глобальном пространстве имен. Пространства имен были созданы для разделения типов на логические контейнеры, поэтому было ясно, к какому типу относится. Это также относится к С#.

Ассембли - это решение для развертывания. Если вы посмотрите на .Net-структуру, данная сборка будет содержать несколько разных пространств имен.

Папка предназначена для организации файлов на диске.

Эти три не имеют ничего общего друг с другом, однако часто бывает удобно, что имя сборки, пространство имен и имена папок одинаковы. Обратите внимание, что Java сворачивает папки и пространства имен в одно и то же (ограничение свободы разработчиков для организации файлов и пространств имен).

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

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

Ответ 8

Я также чувствую боль с этим по умолчанию в Visual Studio.

Visual Studio также пытается установить соответствие пространства имен/каталогов, когда вы помещаете файлы LinqToSql .dbml в свой собственный каталог. Всякий раз, когда я редактирую .dbml, я должен помнить:

откройте файл .dbml.designer.cs
удалите имя каталога/папки из объявления namespace

Там есть способ остановить это поведение. Это связано с созданием шаблона пользовательского класса.

Ответ 9

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

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

В прошлом для меня было полезно создать файл (например, WPF UserControl) в одном месте, чтобы получить пространство имен справа, а затем переместить его в "правую" папку.

Ответ 10

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

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

Скажем, я использую Visual Studio для работы с Unity. Теперь все мои скрипты находятся в пространстве имен "Assets.Scripts". Существует не просто бесполезное пространство имен Assets, которое теперь не содержит скриптов, но "Assets.Scripts" бессмысленно - он не описывает, к какому проекту или части проекта принадлежит исходный файл. Бесполезный.