Есть ли обратная сторона дублирующих квалификаторов?Есть ли польза?

Question

Например, ссылка на что-то как System.Data.Datagrid, а не просто на Datagrid.Приведите примеры и пояснения.Спасибо.

Answer 1

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

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

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

Answer 2

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

using Datagrid = System.Data.Datagrid;

Answer 3

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

Answer 4

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

Я также склонен использовать тег пространства имен для RCW на уровне взаимодействия COM, чтобы явно вызывать эти переменные в коде (им может потребоваться особое внимание в жизненном цикле и сборе), например

using _Interop = Some.Interop.Namespace;

Answer 5

С точки зрения производительности нет плюсов/минусов.Все разрешается во время компиляции, и сгенерированный MSIL идентичен независимо от того, используете ли вы полные имена или нет.

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

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

Answer 6

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

Answer 7

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

Например, я столкнулся с этим с GCC.

struct A {
    int A::b; // warning!
}