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

Question

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

Answer 1

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

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

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

Answer 2

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

using Datagrid = System.Data.Datagrid; 

Answer 3

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

Answer 4

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

Answer 5

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

Я столкнулся с этим с помощью GCC, например.

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

Answer 6

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

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

using _Interop = Some.Interop.Namespace; 

Answer 7

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

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

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