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

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

11 голосов
/ 17 сентября 2010

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

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

С точки зрения человеческого фактора:

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

и т. Д.

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

Спасибо за чтение и заранее спасибо за любую помощь!

Ответы [ 4 ]

19 голосов
/ 17 сентября 2010

Для нетехнических вещей, прочитайте Руководство по проектированию Frameworks. У них много хороших советов. Кратко:

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

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

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

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

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

0 голосов
/ 17 сентября 2010

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

0 голосов
/ 17 сентября 2010

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

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

0 голосов
/ 17 сентября 2010

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

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