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

问题描述

我享受和强烈建议 Juval洛伊的 - 的 C＃编程标准。 Juval明确理由避免为每个指令，以保持标准的紧（见前言）。不过，也有对此我发现自己好奇的理由几个指令。

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.

什么是洛伊的C＃标准以下指令的具体原因是什么？结果
希望有硬（非主观的）回答这些。

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避免完全限定的类型名称。使用使用语句。的结果
这是一个性能问题？有时候，我只需要完全合格的名称的一个实例，加入的使用的似乎沉重。

的 1.26使用空括号在参数的匿名方法。省略仅可以在任何代表已使用匿名方法的括号。的结果
其实我只是用第二条语句混淆。例如用（S）说明会帮忙，谢谢。

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避免定义自定义异常类的结果
什么是尽量减少其数目的考虑？ （他接着给出了指引，如果你做定义它们（2.20）。）

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避免使用三元条件运算符的结果
太难为读者消化，或其他考虑？

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

的 在布尔条件语句2.31避免函数调用。分配到局部变量并检查它们。的结果
我不认为我这样做，但我很好奇......为什么不呢？

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避免接口与一个成员。的结果
，因为它始终/通常比较prefereable做什么？一种方法的接口工作的时候？

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

的 2.53尽量使用显式接口实现的结果
为什么呢？此外，乔恩斯基特不同意这里。

提前感谢！
罗伯特

Thanks in advance! Robert

推荐答案

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

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

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

业绩不能成为问题在这里。我敢肯定，问题是可读性。

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

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"); }; // 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避免定义自定义异常类

再次可读性是这里的问题。框架异常类丰富，易于理解。更换时要小心。

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

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

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避免函数布尔条件语句调用。分配到局部变量并检查它们。

部分，这是可读性强，部分是为了方便调试。我开始只是让他们在调试容易被发现以后几乎所有的临时变量分配。

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" 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尽量使用显式接口实现

这是类似于使用最少的公共存取你可以的想法。如果你的类没有的需求的使界面公众，那么它很可能不应该。这是怎么回事根据您的设计，显然是显著不同，但鉴于大多数人只是使界面隐含没有真正思考它，它的建议值得考虑。

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洛伊的C＃编码标准问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！