Должен ли я согласиться запретить директиву using в моих проектах C#?

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

Кроме того, планируете ли вы запоминать, в каком пространстве имен находится каждый отдельный класс, чтобы иметь возможность ввести его полностью?

Закон Деметры говорит, что вы должны использовать только одна точка:

For many modern object oriented languages that use a dot as field identifier, the law can be stated simply as "use only one dot". That is, the code "a.b.Method()" breaks the law where "a.Method()" does not.

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

Обновлено: этот ответ кажется спорным. Я привел Law of Demeter в основном как руководство по стилю, и большинство ответов здесь, похоже, согласны с тем, что ограничение количества точек - хорошая идея. На мой взгляд, jQuery (и JavaScript) страдают от проблем с удобочитаемостью, отчасти из-за того, что в любую нетривиальную программу закрадывается слишком много точек.

Поскольку у нас есть инструмент на C# для автоматической настройки оператора using, нажав Ctrl + точка, я не вижу причин не использовать его. Другая "крутая" вещь здесь:

Подумайте о том, что у вас есть два пространства имен:

ConsoleNamespace1

и

ConsoleNamespace2

У обоих есть класс Console. Теперь вы можете изменить все ссылки на ConsoleNamespace2 с помощью всего одной строчки кода - это круто.

Мой совет: используйте using, если можете, и полную, если нужно. Я не думаю полностью, если легче читать. Знайте свой фреймворк, и это никогда не будет проблемой.

О, парень. Одним из шагов может быть обучение вашего коллеги работе с ctrl. Он автоматически вставит за вас операторы using.

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

Упрощение перемещения кода путем копирования и вставки - это просто non sequitur и, вполне возможно, предупреждающий знак о потенциально опасной практике. Структура и удобочитаемость кода не должны зависеть от простоты редактирования.

Во всяком случае, это делает код менее читаемым и более конкретным - лично меня не интересует, где находятся стандартные объекты, это похоже на обращение к вашему коллеге по его полному имени с префиксом уличного адреса вашего рабочего места.

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

Я рекомендую против предложения вашего коллеги. Для меня чтение кода намного проще, если у вас нет длинного пространства имен, загромождающего строку. Только представьте себе это:

Namespace1.Namespace2.Namespace3.Type var = new Namespace1.Namespace2.Namespace3.Type(par1, par2, par3);

в отличие от:

Type var = new Type(par1, par2, par3);

Что касается копирования и вставки - у вас есть Shift + Alt + F10, который добавит пространство имен, так что это не должно быть проблемой.

Что я думаю об этом?

Я думаю, что человек, который придумал бы такую ​​идею и который оправдывал бы ее таким образом, скорее всего, будет иметь ряд других фундаментальных недоразумений относительно языка C# и разработки .NET.

Также стоит отметить, что такой инструмент, как ReSharper (почему вы его еще не используете?), В значительной степени автоматически добавит для вас соответствующие строки «using».

Для немного другого ответа: LINQ.

Методы расширения можно получить только с помощью операторов using. Таким образом, либо синтаксис запроса, либо свободный интерфейс Только будет работать с правильными операторами using.

Даже без LINQ я бы сказал использовать "using" ... рассуждая о том, что чем больше вы сможете понять с помощью меньшего количества символов, тем лучше. Некоторые пространства имен очень глубокие, но не добавляют ценности вашему коду.

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

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

Одна из причин, по которой вы используете слово using, заключается в том, что оно сообщает любому, кто читает исходный текст, что будет делать ваш класс. Использование System.IO сообщает читателю, что вы, например, выполняете операции ввода-вывода.

Вы также можете использовать псевдонимы ...:

using diagAlias = System.Diagnostics;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            diagAlias.Debug.Write("");
        }
    }
}

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

Module Module1

    Sub Main()
        Dim Rgx As New System.Text.RegularExpressions.Regex("Pattern", _
            System.Text.RegularExpressions.RegexOptions.IgnoreCase _
            Or System.Text.RegularExpressions.RegexOptions.Singleline _
            Or System.Text.RegularExpressions.RegexOptions.IgnorePatternWhitespace)


        For Each result As System.Text.RegularExpressions.Match In Rgx.Matches("Find pattern here.")
            'Do Something
        Next
    End Sub

End Module

И это

Imports System.Text.RegularExpressions

Module Module1

    Sub Main()
        Dim Rgx As New Regex("Pattern", _
            RegexOptions.IgnoreCase _
            Or RegexOptions.Singleline _
            Or RegexOptions.IgnorePatternWhitespace)


        For Each result As Match In Rgx.Matches("Find pattern here.")
            'Do Something
        Next
    End Sub

End Module

В таких случаях, когда используется множество перечислений, а также объявление ваших переменных встроенными в цикл for для уменьшения области действия, отказ от использования «использования» или «импорта» в случае vb.Net может привести к очень плохой читаемости. .

Вы действительно хотите поддерживать код таким образом? Даже с intellisense набор текста не будет продуктивным.

Вместо «копировать и вставлять» я называю это «копирование и изнасилование», потому что код используется в 99,9% случаев, когда он проходит через этот процесс. Итак, вот мой ответ на аргумент №1 вашего коллеги в пользу такого подхода.

Кстати, такие инструменты, как Resharper, будут добавлять операторы using вверху, когда вы добавляете код, который нуждается в них, в ваш код (так что даже если вы «копируете-н-насилуете» такой код, вы можете сделать это легко).

Помимо личных предпочтений, я думаю, что ваши обоснования намного ценнее его, поэтому, даже если предположить, что все они верны, я все равно рекомендую писать операторы using вверху. Я бы не стал называть это «запретом», поскольку я рассматриваю стандарт кодирования как руководство, а не как правила. В зависимости от размера вашей команды может быть очень сложно обеспечить соблюдение таких вещей (или сколько пробелов для отступов, или стилей отступов и т. д.).

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

Как только ваш коллега сказал «скопируйте и вставьте код», он потерял всякое доверие.

Я думаю, что с функциями IntelliSense в Visual Studio и с использованием некоторых сторонних продуктов, таких как ReSharper, мы больше не заботимся о том, чтобы сделать наш код полностью квалифицированным или нет. Разрешение пространств имен при копировании и вставке кода больше не занимало много времени.

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

Со всеми имеющимися у нас стандартными классами .NET мы просто используем операторы using.

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

Некоторые системы выбирают первый вариант. Тогда ваши директивы using смогут сокращать имена, которые вы используете чаще всего.

В .NET это последнее. Например, рассмотрим System.Xml.Serialization.XmlSerializationReader. Обратите внимание на дублирование между пространством имен и типом. Это потому, что в этой модели имена типов должны быть уникальными даже в разных пространствах имен.

Если я правильно помню, вы можете найти это, описанное командой CLR здесь: http://blogs.msdn.com/kcwalina/archive/2007/06/01/FDGLecture.aspx

Its simpler to copy and paste code into other source files.

Верно, но если вы копируете / вставляете много кода, вы, вероятно, делаете это неправильно.

It is more readable (you see the namespaces right away)

Просмотр пространств имен не важен, поскольку, по крайней мере, когда вы следуете рекомендациям Microsoft, имена типов уже уникальны; пространство имен на самом деле не дает вам полезной информации.

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

Это также помогает мне понять, есть ли у меня уже соответствующие ссылки в проекте. Например, если я напишу System.Web.UI, но не могу найти расширения, тогда я знаю, что забыл / кто когда-либо создавал проект, забыл вставить ссылки ASP.NET AJAX.

В наши дни я делаю это все реже и реже, поскольку использую ярлык для определения класса (Ctrl +.). Если вы наберете имя класса (в правильном регистре) и нажмете этот ярлык, вы можете легко полностью проверить / добавить оператор using.

Это отлично подходит для StringBuilder, у меня никогда не было System.Text, поэтому я просто набираю StringBuilder -> Ctrl +. и поехали, я добавил using.

«В ту минуту, когда ваш коллега сказал« скопируйте и вставьте код », он потерял всякое доверие». то же самое.

«Закон Деметры гласит ...» то же самое

... и я добавляю. Это просто абсурд, не использовать операторы using. Получите ReSharper, найдите способ научить этого парня, как это делается, и если это не сработает - с указанными причинами пора начать искать другую работу. Просто корреляция того, что идет вместе с такими понятиями, как отказ от использования операторов, пугает. Вы будете работать 16 часов в день, устраняя беспорядок, если это одно из правил. Невозможно предсказать, с каким еще видом оскорбления здравого смысла и логики вы столкнетесь в следующий раз.

Если серьезно, то это даже не следует поднимать с помощью таких инструментов, как ReSharper. Деньги тратятся зря, купите ReSharper, очистите код и вернитесь к созданию удобного программного обеспечения. :) Это мои 2 цента.

если вы многократно копируете и вставляете код, разве это не означает создание стандартной библиотеки DLL для включения в каждый из ваших проектов?

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

Разве тот факт, что Visual Studio включает множество операторов using в верхней части почти каждого файла, не является намеком на то, что операторы using считаются хорошей практикой?

Программирую 25 лет. ИСПОЛЬЗОВАНИЯ важны и должны использоваться всегда, и это хорошая практика кодирования. ОДНАКО любой хороший разработчик должен иметь репозиторий кода. Совместное использование фрагментов кода намного проще, если включить полностью определенные пространства имен.

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