Более широкий вопрос:
Вы когда-нибудь слышали о введении такого стандарта? Если так, то в чем причина?
Да, я слышал об этом, и использование полностью определенных имен объектов предотвращает конфликты имен. Хотя они случаются редко, они могут быть чрезвычайно сложными для понимания.
Пример.
Этот тип сценария, вероятно, лучше объяснить на примере.
Допустим, у нас есть два, Lists<T>
принадлежащих к двум отдельным проектам.
System.Collections.Generic.List<T>
MyCorp.CustomCollections.Optimized.List<T>
Когда мы используем полное имя объекта, становится ясно, какое из List<T>
них используется. Эта ясность, очевидно, достигается ценой многословия.
И вы можете спорить: «Подождите! Никто никогда не использовал бы два таких списка!» Вот где я укажу сценарий обслуживания.
Вы написали модуль Foo
для своей корпорации, который использует одобренную, оптимизированную корпорацию List<T>
.
using MyCorp.CustomCollections.Optimized;
public class Foo {
List<object> myList = ...;
}
Позже новый разработчик решает расширить работу, которую вы выполняете. Не зная о стандартах компании, они обновляют using
блок:
using MyCorp.CustomCollections.Optimized;
using System.Collections.Generic;
И вы можете видеть, как дела идут плохо в спешке.
Следует отметить, что вы можете иметь два проприетарных класса с одним и тем же именем, но в разных пространствах имен в одном проекте. Так что речь идет не только о столкновении с классами, поставляемыми в .NET Framework.
MyCorp.WeightsAndLengths.Measurement();
MyCorp.TimeAndSpace.Measurement();
Реальность:
В
настоящее время, это , вероятно , произойдет в большинстве проектов? Нет, не совсем. Но когда вы работаете над большим проектом с большим количеством входов, вы делаете все возможное, чтобы свести к минимуму вероятность того, что на вас взорвется.
Крупные проекты с несколькими участвующими командами являются особым видом зверя в мире приложений. Правила, которые кажутся необоснованными для других проектов, становятся более уместными из-за входных потоков в проект и вероятности того, что участники не прочитали руководящие принципы проекта.
Это также может произойти, когда два больших проекта объединены вместе. Если у обоих проектов были классы с одинаковыми именами, вы увидите столкновения, когда начнете ссылаться из одного проекта в другой. И проекты могут быть слишком большими для рефакторинга, или руководство не утвердит расходы для финансирования времени, потраченного на рефакторинг.
Альтернативы:
Хотя вы не спрашивали, стоит отметить, что это не лучшее решение проблемы. Не стоит создавать классы, которые будут сталкиваться без объявлений их пространств имен.
List<T>
в частности, его следует рассматривать как зарезервированное слово, а не как имя для ваших классов.
Аналогично, отдельные пространства имен в проекте должны стремиться иметь уникальные имена классов. Необходимость попытаться вспомнить, с каким пространством имен Foo()
вы работаете, - это ментальные накладные расходы, которых лучше избегать. Сказал по-другому: иметь MyCorp.Bar.Foo()
и MyCorp.Baz.Foo()
собирается сбить с толку ваших разработчиков и лучше избегать.
Если ничего другого, вы можете использовать частичные пространства имен для устранения неоднозначности. Например, если вы абсолютно не можете переименовать один из Foo()
классов, вы можете использовать их частичные пространства имен:
Bar.Foo()
Baz.Foo()
Конкретные причины вашего текущего проекта:
Вы обновили свой вопрос, указав конкретные причины, по которым вы указали свой текущий проект в соответствии с этим стандартом. Давайте посмотрим на них и действительно отвлечемся по следу кролика.
Наводить указатель мыши на имя, чтобы получить полностью определенный тип, будет неудобно. Лучше всегда иметь полностью определенный тип, видимый все время.
«Громоздкий?» Нет Раздражает возможно. Перемещение нескольких унций пластика для перемещения экранной указки не является громоздким . Но я отвлекся.
Эта линия рассуждений больше похожа на сокрытие, чем на что-либо еще. Случайно, я бы предположил, что классы в приложении имеют слабые имена, и вы должны полагаться на пространство имен, чтобы собирать соответствующее количество семантической информации, окружающей имя класса.
Это недопустимое обоснование для полностью определенных имен классов, возможно, это правильное обоснование для использования частично определенных имен классов.
Фрагменты кода, отправленные по электронной почте, не имеют полностью определенного имени, и поэтому могут быть трудны для понимания.
Эта (продолжение?) Аргументация усиливает мое подозрение, что классы в настоящее время плохо названы. Опять же, наличие плохих имен классов не является хорошим оправданием для требования, чтобы все использовали полное имя класса. Если имя класса трудно понять, есть намного больше ошибок, чем то, что могут исправить полные имена классов.
При просмотре или редактировании кода вне Visual Studio (например, Notepad ++) невозможно получить полное имя типа.
Из всех причин эта чуть не заставила меня выплюнуть напиток. Но я опять отвлекся.
Мне интересно, почему команда часто редактирует или просматривает код за пределами Visual Studio? И теперь мы смотрим на обоснование, которое довольно хорошо ортогонально тому, что должны предоставить пространства имен. Это аргумент, поддерживаемый инструментами, тогда как пространства имен служат для обеспечения организационной структуры кода.
Похоже, что ваш проект страдает от плохих соглашений об именах вместе с разработчиками, которые не пользуются преимуществами того, что инструмент может им предоставить. И вместо того, чтобы решить эти реальные проблемы, они пытаются нанести лейкопластырь на один из симптомов и требуют полностью квалифицированных имен классов. Я думаю, что это можно отнести к категории ошибочного подхода.
Принимая во внимание, что существуют плохо названные классы, и при условии, что вы не можете выполнить рефакторинг, правильный ответ - использовать Visual Studio IDE в полной мере. Возможно, рассмотрите возможность добавления в плагин, такой как пакет VS PowerTools. Затем, когда я смотрю, AtrociouslyNamedClass()
я могу щелкнуть имя класса, нажать F12 и перейти непосредственно к определению класса, чтобы лучше понять, что он пытается сделать. Кроме того, я могу нажать Shift-F12, чтобы найти все места в коде, которые в настоящее время нуждаются в использовании AtrociouslyNamedClass()
.
Что касается внешних проблем с инструментами, лучше всего просто остановить их. Не посылайте фрагменты по электронной почте взад и вперед, если они не сразу понимают, на что ссылаются. Не используйте другие инструменты вне Visual Studio, так как эти инструменты не обладают интеллектом вокруг кода, который нужен вашей команде. Notepad ++ - потрясающий инструмент, но он не предназначен для этой задачи.
Поэтому я согласен с вашей оценкой в отношении трех конкретных обоснований, которые вам были представлены. Тем не менее, я думаю, что вам сказали: «У нас есть основные проблемы в этом проекте, которые не могут / не будут решаться, и именно так мы их« исправили »». И это, очевидно, говорит о более глубоких проблемах в команде, которые могут служить для вас «красными флагами».