Juval Lowy的C＃编码标准问题 [英] Juval Lowy's C# Coding Standards Questions

问题描述

我喜欢并强烈推荐 Juval Lowy的 - C＃编码标准。 Juval明确地避免了每个指令的理由，以保持标准紧密（见前言）。然而，有一些指令，我发现自己对这个理由很好奇。

来自Lowy的C＃标准的以下指令的具体原因是什么？

希望有硬主观的）答案。

1.13避免使用完全限定的类型名称。请改用using语句。

这是性能问题吗？

1.26使用空圆括号无参数匿名方法。

实际上，我只是对第二句话感到困惑。

最小化他们的数字有什么考虑？

2.29避免使用三元条件运算符

为了让读者消化或其他考虑因素太费力？

2.31避免在布尔条件语句。分配到局部变量并检查它们。

我不认为我这样做，但我很好奇...为什么不？

2.47避免与一个成员的接口。

因为总是/通常更容易做什么？一个方法接口工作时

2.53优先使用显式接口实现

为什么？此外， Jon Skeet在此不同意。

提前感谢！
Robert

解决方案

显然，我不是Juval，但我可以在这些

1.13避免使用完全限定类型名称。请改用using语句。

这里的性能不是问题。我确定问题是可读性。

1.26对无参数匿名方法使用空括号。

  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）; }; //不编译
} 
  

没有括号，匿名代理可以应用于任何代表。使用括号，您将具体说明代理的签名。

$ b

2.19避免定义自定义异常类 b

同样，可读性是这里的问题。框架异常类是丰富和易于理解的。

这是一个可读性和可扩展性的东西。我不是真的同意，但它是一个标准的宗教斗争。

2.31避免布尔条件语句中的函数调用。分配到局部变量并检查它们。

部分这是可读性，部分是为了便于调试。我已经开始将几乎所有的东西分配给临时变量，以便稍后在调试器中轻松找到它们。

2.47避免与一个成员接口。

避免有点喜欢喜欢，他只是在你做之前三思。如果你只有一个成员，是真的建模一些有用的和完整的设计中的接口？

2.53更喜欢使用显式接口实现

这类似于使用最小公共访问器的想法。如果你的类不需要使接口公开，那么它可能不应该。这显然会根据你的设计有很大的不同，但是考虑到大多数人只是让界面隐含而不去真正思考它，这是值得考虑的建议。

I enjoy and highly recommend Juval Lowy's - C# Coding Standard. Juval explicitly avoids rationale for each directive in order to keep the standard tight (see the preface). However, there are a few directives for which I find myself curious as to the rationale.

What is the specific rationale to the following directives from Lowy's C# standard?
Hopefully there are hard (non-subjective) answers to these.

1.13 Avoid fully qualified type names. Use the "using" statement instead.
Is this a performance issue? Sometimes I only need one instance of the fully qualified name and adding a using seems heavy.

1.26 Use empty parenthesis on parameterless-anonymous methods. Omit the parenthesis only if the anonymous method could have been used on any delegate.
Actually I am just confused by the second sentence. Explanation with example(s) would help, thank you.

2.19 Avoid defining custom exception classes
What are the considerations in minimizing their numbers? (He next gives guidelines if you do define them (in 2.20).)

2.29 Avoid using the ternary conditional operator
Too hard for the reader to digest, or other considerations?

2.31 Avoid function calls in Boolean conditional statements. Assign into local variables and check on them.
I don't think I do this, but I am curious...why not?

2.47 Avoid interfaces with one member.
Because it is always/usually more prefereable to do what? One method interfaces work when?

2.53 Prefer using explicit interface implementation
Why? Also, Jon Skeet disagrees here.

Thanks in advance! Robert

解决方案

Obviously, I'm not Juval, but I can take a stab at these

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

Performance can't be the issue here. I'm sure the issue is readability.

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
}

Without the parens, the anonymous delegate can be applied to any delegate. With the parens, you're being specific about the signature of the delegate. Prefer the second syntax unless you really need the flexibility.

2.19 Avoid defining custom exception classes

Again, readability is the issue here. The framework exception classes are rich and well-understood. Be wary when replacing them.

2.29 Avoid using the ternary conditional operator

It's a readability and expandability thing. I don't really agree, but it's a standard religious fight.

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

Partially this is readability, and partially it's for ease of debugging. I've starting to assign almost everything to temporary variables just so that they're easily found in the debugger later on.

2.47 Avoid interfaces with one member.

"Avoid" is kinda like "prefer", he's just saying think twice before you do it. If you only have one member, is the interface really modeling something useful and complete in your design? It's pretty rare to have a class with just one member, think seriously about why your interface is any different.

2.53 Prefer using explicit interface implementation

This is similar to the idea of using the least-public accessor you can. If your class doesn't need to make the interface public, then it probably shouldn't. This is going to differ significantly based on your design, obviously, but given the fact that most people just make the interface implicit without really thinking about it, it's advice worth considering.

这篇关于Juval Lowy的C＃编码标准问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！