Подтвердить что ты не робот

Должен ли я согласиться запретить "использование" директивы моих проектов на С#?

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

public class MyClass
{
    public static void Main()
    {
        System.Console.WriteLine("Foo");
    }
}

вместо:

using System;
public class MyClass
{
    public static void Main()
    {
        Console.WriteLine("Foo");
    }
}

Вы можете представить себе последствия.

Профи, которые он дает:

  • Проще копировать и вставлять код в другие исходные файлы.
  • Это более читаемо (вы сразу видите пространства имен).

Мои минусы:

  • Мне нужно написать больше
  • Код менее читабельен (я думаю, gustibus non dissandum est)
  • Никто этого не делает!

Что вы думаете об этом?

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

В тот момент, когда ваш коллега сказал "код копирования и вставки", он потерял всякое доверие.

Ответ 5

Самая большая проблема, с которой я сталкиваюсь, не используя директиву "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, может привести к действительно плохо читаемость.

Ответ 6

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

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

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

Ответ 7

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

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

ConsoleNamespace1

и

ConsoleNamespace2

Оба имеют класс консоли. Теперь вы можете изменить все ссылки на ConsoleNamespace2, используя только одну строку кода - это круто.

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

Ответ 13

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

using diagAlias = System.Diagnostics;

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

Ответ 14

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

Ответ 15

"В тот момент, когда ваш коллега сказал" код копирования и вставки ", он потерял все доверие". то же самое.

"Закон Деметры говорит..." ditto

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

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

Ответ 16

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

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

Ответ 17

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

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

Ответ 18

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

Для многих современных объектно-ориентированных языков, использующих точку в качестве идентификатора поля, закон можно сформулировать просто как "использовать только одну точку". То есть код "a.b.Method()" нарушает закон, где "a.Method()" не делает.

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

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

Ответ 19

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

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

в отличие от:

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

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

Ответ 20

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

Ответ 21

Вместо "copy-n-paste" я называю это "copy-n-rape", потому что код злоупотребляет 99,9% случаев, когда он выполняется через этот процесс. Так вот, мой ответ на оправдание вашего коллеги №1 для этого подхода.

На стороне примечания инструменты, такие как Resharper, будут добавлять операторы using вверху, когда вы добавляете код, который им нужен, в ваш код (так что даже если вы используете код "copy-n-rape", который вы можете сделать так легко).

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

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

Ответ 22

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

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

Ответ 23

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

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

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

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

Его проще скопировать и вставить код в другие исходные файлы.

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

Это более читаемо (вы сразу видите пространства имен)

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

Ответ 24

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

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

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

Это здорово для StringBuilder, у меня никогда не было System.Text, поэтому я просто набираю StringBuilder → Ctrl+. и там мы идем, я добавил использование.

Ответ 25

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