23

Вопрос по c# – Вопросы о стандартах кодирования C # Ювала Лоуи

Я наслаждаюсь и очень рекомендуюЮваль Лоуи - C # Стандарт кодирования, Юваль явно избегает обоснования для каждой директивы, чтобы придерживаться стандарта (см. Предисловие). Однако есть несколько директив, для которых я нахожу себя любопытным в отношении обоснования.

What is the specific rationale to the following directives from Lowy's C# standard?
Надеемся, что есть жесткие (не субъективные) ответы на них.

1.13 Avoid fully qualified type names. Use the "using" statement instead.
Это проблема с производительностью? Иногда мне нужен только один экземпляр полного имени и добавлениеusing кажется тяжелым.

1.26 Use empty parenthesis on parameterless-anonymous methods. Omit the parenthesis only if the anonymous method could have been used on any delegate.
На самом деле я просто смущен вторым предложением. Объяснение с примерами поможет вам, спасибо.

2.19 Avoid defining custom exception classes
Каковы соображения при минимизации их числа? (Затем он дает указания, если вы их определите (в 2.20).)

2.29 Avoid using the ternary conditional operator
Слишком сложно для читателя переварить или другие соображения?

2.31 Avoid function calls in Boolean conditional statements. Assign into local variables and check on them.
Я не думаю, что делаю это, но мне любопытно ... почему бы и нет?

2.47 Avoid interfaces with one member.
Потому что всегда / обычно предпочтительнее делать что? Один метод интерфейсы работают когда?

2.53 Prefer using explicit interface implementation
Зачем? Также,Джон Скит не согласен здесь.

Заранее спасибо! Роберт

  • Error: User Rate Limit Exceeded

    от
  • Error: User Rate Limit Exceeded

    от
  • Error: User Rate Limit Exceeded

    от
  • Error: User Rate Limit Exceeded

    от
  • 2.29: условным оператором легко злоупотреблять, но иногда удобно. Я бы не колебался использовать его там, где это уместно. 2.31: обоснование, которое вы дали, похоже на классический пример применения YAGNI.

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

    от
  • Я думаю, что Роберт согласился с 2.31 и предоставил больше информации о том, почему. теперь у вас есть локальный с данными вместо их отбрасывания в условной оценке.

    от
  • хорошие ответы имо, очень прагматичный подход

    от
  • согласовано. Я думаю, что использование для копирования данных объекта является наиболее полезным и положительно влияет на удобочитаемость. Когда у вас есть ряд свойство = значение; линий. наличие блока if / else становится отрицательным для читабельности.

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

    от RAL
  • @devinb - я так думаю. Я думал, что было бы полезнее хранить их всех в одном месте, потому что ... ну, потому что они все пришли из одного места, и я подумал, что будет странно повторить преамбулу к вопросу для каждого. Теперь я понимаю, как мне труднее выбрать один из них в качестве правильного ответа ... мой плохой!

    от RAL
  • Я думаю, что SO эксперты могут на самом деле "знать" ответы. Мне действительно нужно разбить это на 7 вопросов? Меня постоянно укусила ошибка вики сообщества, очень расстраивающая.

    от RAL
  • Увидев, как Ювал говорит (TechEd несколько лет назад), он выглядит довольно педантично, но у него есть причины упростить использование. Это не означает, что я согласен, и рекомендации, приведенные в «Руководстве по разработке структуры» являются более всеобъемлющими и (IMO) лучше.

    от Richard
  • Вы правильно разместите их все в одном месте. Но это когда вы помечаете вопрос как CW.

    от DevinB
  • Я думаю, что это должна быть вики сообщества, так как будет много одиночных ответов, а «правильных» нет. ответь, если сам Юваль не пойдет по трубам.

    от DevinB
8 ответов
  • 10

    // This is fine

    2.29 Avoid using the ternary conditional operator  У меня нет проблем с & quot; простым & quot; использует троичный оператор, но рекомендовал не использовать его во вложенном виде:

    x := (conditionA) ? true_resultA : false_resultA;
    
    // This would probably be clearer using if-then-elseif
    x := (conditionA) ? 
           ((conditionA1) ? true_resultA1 : (condition2) ? true_result2 : false_result2) :
           ((conditionA2) ? true_resultA2 : false_resultA2);
    

  • 0

    2.29 Ternary operator

    Для начала, если вы начнете использовать троичный оператор, должна быть причина для использования троичного оператора вместо обычного if-then-else. Соблюдайте:

    if (x == 0) {...} else{...} //A set of statements demand a regular If-then-else
    
    //A simple assignment can be handled by the ternary operator
    y = (x == 0)? 1 : 0 //this is readable and how it should be used
    
    
    (x==0)? callSomething() : callSomethingElse() //this is NOT how it should be used
    

    Тернарный оператор предназначен для возврата одного из двух значений в зависимости от того, какое условие он оценивает. Это очень удобно при выполнении FP. Для операторов вызова, которые не возвращают значение, вы должны вернуться к if-then-else.

  • 5

    // #1 Empty parenthesis on parameterless-anonymous methods would be:

    1.26 о предварительной лямбдеdelegate { } синтаксис.

    delegate() { }
    // #2 ... anonymous method could have been used on any delegate, is:
    delegate { }
    

    Помните, что последний может быть назначенany делегат, независимо от его параметров. Делегат просто игнорирует их, используя некоторые хитрости компилятора.

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

  • 3

    Это мой лучший ответ на вопросы

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

    1.13 Avoid fully qualified type names. Use the "using" statement instead.

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

    2.19 Avoid defining custom exception classes

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

    2.29 Avoid using the ternary conditional operator

    Я думаю, что это наиболее вероятно, потому что он думает, что люди могут не понимать оператора, но я не согласен.

    2.47 Avoid interfaces with one member.

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

    2.31 Avoid function calls in Boolean conditional statements. Assign into local variables and check on them.

    Несколько причин я могу думать здесь. Читаемость. Это может затруднить понимание условных операторов, если вы выполняете в них вызовы функций. Кроме того, его сложнее отлаживать, если вы не смотрите.

    2.53 Prefer using explicit interface implementation

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

  • 4

    Относительно 1.13 (избегайте полностью определенных имен типов. Вместо

    этого используйте оператор & quot; using & quot;):

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

    Класс кричит на рефакторинг. Использование использования вместо полностью определенных имен классов позволяет легче идентифицировать такие тесно связанные классы.

  • 4

    Многие из этих рекомендаций говорят

    "quality attributes" of good software design (то есть ремонтопригодность, надежность, возможность повторного использования, тестируемость, расширяемость, отлаживаемость, совместимость и другие возможности, которые вы можете назвать).

    Часто люди создают код, который отлично работает в то время, но, возможно, не является лучшим выбором при рассмотрении всех атрибутов качества (в смысле «куда может пойти это программное обеспечение»).in the future& Quot; или "этот код тоже должен использовать кто-то другой").

    Например:

    2.29 Avoid using the ternary conditional operator

    У меня нет проблем с троичными выражениями как таковыми, но я пишу такой код:int result = CheckMethod() ? OnTrueDoThis() : OnFalseDoThat()... вы говорите: "У меня есть условие, что, если истина (или ложь), вы можете сделатьone and only one thing. & Quot; Вся конструкцияdiscourages expandability, Вы должны воссоздать конструкцию (с помощью оператора if..else).

    Так же...

    2.31 Avoid function calls in Boolean conditional statements. Assign into local variables and check on them.

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

    Наслаждаться,

    Роберт К. Картейно

  • 9

    Очевидно, я не Юваль, но я могу нанести удар по этим

    1.13 Avoid fully qualified type names. Use the "using" statement instead.

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

    1.26 Use empty parenthesis on parameterless-anonymous methods. Omit the parenthesis only if the anonymous method could have been used on any delegate.

    public delegate void Foo1();
    public delegate void Foo2(int val);
    
    public void Foo()
    {
        Foo1 first = delegate { Console.WriteLine("Hello world"); };
        Foo2 second = delegate { Console.WriteLine("Hello world"); };
        Foo1 third = delegate() { Console.WriteLine("Hello world"); };
        Foo2 fourth = delegate() { Console.WriteLine("Hello world"); }; // does not compile
    }
    

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

    2.19 Avoid defining custom exception classes

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

    2.29 Avoid using the ternary conditional operator

    Это вещь читабельности и расширяемости. Я не совсем согласен, но это стандартная религиозная борьба.

    2.31 Avoid function calls in Boolean conditional statements. Assign into local variables and check on them.

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

    2.47 Avoid interfaces with one member.

    & Quot; Избегайте & Quot; это как «предпочесть», он просто говорит, что дважды подумай, прежде чем сделать это. Если у вас есть только один участник, действительно ли интерфейс моделирует что-то полезное и законченное в вашем дизайне? Довольно редко бывает, когда класс состоит только из одного участника, серьезно подумайте о том, почему ваш интерфейс отличается.

    2.53 Prefer using explicit interface implementation

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

  • 2

    Вот некоторые из моих реакций, на которые я смею на них отвечать :)

    1.13 Avoid fully qualified type names. Use the "using" statement instead. Я не согласен. Это, безусловно, не связано с производительностью. Этоcan привести к улучшению читабельности, чтобы иметьvar foo = new Foo() вместоvar foo = new MyCompany.MyNamespace.Helpers.Xml.Foo() но кроме этого - нет.

    2.19 Avoid defining custom exception classes Это ерунда имхо. Вам следует избегать создания пользовательских исключений, которые являются производными от ApplicationException, но нет ничего плохого в пользовательских исключениях (если вы не собираетесь заново изобретать существующие исключения).

    2.29 Avoid using the ternary conditional operator Я понятия не имею, почему это будет руководящим принципом. Я читал, что не все люди используют его и могут не распознать, но это не является веской причиной, чтобы не использовать полезный оператор.

    2.31 Avoid function calls in Boolean conditional statements. Assign into local variables and check on them. На мой взгляд, это просто вопрос читабельности.

    2.47 Avoid interfaces with one member. Я также не согласен здесь. Вам следует избегать «маркера» хотя интерфейсы - интерфейсы без маркера, но которые служат только для того, чтобы что-то было "бледно". Но один метод интерфейса мне кажется вполне подходящим.