Есть ли недостаток в избыточных классификаторах? Любая выгода?

Question

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

Answer 1

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

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

using _Interop = Some.Interop.Namespace;

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

using Datagrid = System.Data.Datagrid;

Answer 6

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

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

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

Answer 7

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