Что я должен знать при выборе имени пространства имен?

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

Что делает для меня "неправильное" пространство имен?

В терминах человеческих факторов:

Аббревиатура, которая по существу бессмысленна: DDL, MOS и т.д.
Пространство имен, которое сталкивается с общим с другим поставщиком, например Office или Text или IO
Пространство имен, которое трудно произнести или произнести для не-носителей английского языка, потому что это либо иностранное слово, либо собственное имя: Vancouver

и т.д.

Мне комфортно выбирать пространство имен с точки зрения описательной способности и мнемоники. Мне интересно, каковы технические последствия имен пространства имен. Например, какие проблемы могут возникнуть из пространства имен _, который является законным именем пространства имен С#? Как насчет одной буквы, например e? Существуют ли пространства имен, которые дают CodeDom или Reflector? Некоторые пространства имен, которые являются законными в С#, вызывают проблемы на других языках .Net? По какой-либо причине можно выбрать пространство имен, которое не является Mono-compliant? Вы работали с пространством имен, которое затруднило вашу жизнь по причинам, связанным с компилятором или Visual Studio или файловой системой Windows (или Linux)?

Спасибо за то, что прочитали и заблаговременно за помощь!

Ответ 1

Для нетехнических материалов ознакомьтесь с Руководством по дизайну каркасов. У них много хороших советов. Вкратце:

Начните с названия компании.
выберите стабильные (не зависящие от версии) имена. FrobCorp.FrobozzleV2.Utilities - это плохо.
выберите имена, которые отражают цель кода, а не политику организации, которая ее создала. FrobCorp.AdvancedResearchDivision.CambridgeOffice - это плохо; AdvancedResearchDivision может быть переименован завтра, и офис Cambridge может быть перемещен.
используйте PascalCase, если это не нарушает ваш брендинг. FrobCorp.jFrobozzle выглядит ужасно, но FrobCorp.Jfrobozzle выглядит еще хуже.
используйте множественные значения, если это необходимо.
и т.д.

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

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

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

http://blogs.msdn.com/b/ericlippert/archive/tags/namespaces/

Ответ 2

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

 YourCompanyName.subnamespace.subsubnamespace
 YourLastName.YourFirstName.subnamespace.subsubnamespace

Ответ 3

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

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

Ответ 4

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