[我很喜欢并强烈推荐Juval Lowy's-C# Coding Standard。 Juval明确避免了每个指令的理由，以保持标准严格（请参见前言）。但是，我发现有些指令对基本原理感到好奇。
Lowy的C＃标准中以下指令的具体原理是什么？希望对此有硬性（非主观的）答案。
1.13避免使用完全限定的类型名称。改为使用“ using”语句。这是性能问题吗？有时我只需要一个全限定名称的实例，并且添加using似乎很繁琐。
1.26在无参数匿名方法上使用空括号。仅当可以在任何委托上使用匿名方法时，才省略括号。其实我只是对第二句话感到困惑。举例说明会有所帮助，谢谢。
2.19避免定义自定义异常类最小化数量有哪些考虑？ （如果您确实定义了准则，则他接下来会给出准则（在2.20中）。）
2.29避免使用三元条件运算符读者难以理解或其他考虑？
2.31避免在布尔条件语句中调用函数。分配给局部变量并检查它们。我不认为我这样做，但是我很好奇...为什么不呢？
2.47避免与一个成员建立接口。因为总是/通常更喜欢做什么？一种方法接口何时起作用？
2.53建议使用显式接口实现为什么？另外，Jon Skeet disagrees here。
谢谢！罗伯特
显然，我不是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"); }; // does not compile
}
没有括号，匿名委托可以应用于任何委托。使用括号，您可以明确代表的签名。除非确实需要灵活性，否则最好使用第二种语法。
2.19避免定义自定义异常类
同样，可读性是这里的问题。框架异常类丰富且易于理解。更换它们时要小心。
2.29避免使用三元条件运算符
这是可读性和可扩展性。我真的不同意，但这是一场标准的宗教斗争。
2.31避免在布尔条件语句中调用函数。分配给局部变量并检查它们。
部分是可读性，部分是为了易于调试。我已经开始将几乎所有内容分配给临时变量，以便稍后在调试器中轻松找到它们。
2.47避免与一个成员建立接口。
“避免”有点像“喜欢”，他只是说三思而后行。如果您只有一个成员，那么该接口在您的设计中是否真的对建模有用且完整？只有一个成员的类，很少认真考虑一下您的界面为何有什么不同是非常罕见的。
2.53建议使用显式接口实现
这类似于使用最小公共访问器的想法。如果您的班级没有需要公开接口，则可能不应该这样做。显然，这将根据您的设计而有很大的不同，但是鉴于大多数人只是在没有真正考虑的情况下使接口隐式存在，因此值得考虑的建议。
2.29避免使用三元条件运算符我对三元运算符的“简单”用法没有问题，但建议不要以嵌套方式使用它：
// This is fine
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);
1.26与lambda之前的delegate { }语法有关。
// #1 Empty parenthesis on parameterless-anonymous methods would be:
delegate() { }
// #2 ... anonymous method could have been used on any delegate, is:
delegate { }
记住，后者可以分配给any委托，无论其参数如何。委托只是使用一些编译器技巧来忽略它们。
如果您定义不带参数的委托，请使用＃1明确表示。不要“不要加上括号，因为您的代表始终不接受任何参数”。
关于1.13（避免使用完全限定的类型名。请改为使用“ using”语句：]
可能不只是可读性。如果文件开头的使用情况过多，则您有一个类，该类与来自太多名称空间的类结合使用。
该类正在大声疾呼进行重构。使用usings代替完全限定的类名，可以使您更轻松地识别这种紧密耦合的类。
这些指南中有很多都谈到了良好的软件设计的“品质属性”（即可维护性，可靠性，可重用性，可测试性，可扩展性，可调试性，互操作性以及您可以指定的其他功能）。
通常人们会创建当时可以正常工作的代码，但是考虑所有质量属性时（（“将来该软件可以运往将来）>”或“其他人必须也使用此代码”）。
例如：
，但是通过编写如下代码：int result = CheckMethod（）？ OnTrueDoThis（）：OnFalseDoThat（） ...您在说，“我有一个条件，如果为true（或false），则您可以做一件事情，只有一件事情”。整个构造阻止扩展性。您必须重新创建构造（使用if..else语句）。类似地...2.29避免使用三元条件运算符
我对三元表达式没有问题，[[本身
供以后使用。如果以后需要该信息，则必须再次调用该函数，或者必须重写代码的结构。这也会使检查或记录结果（以供将来调试）更加困难。2.31避免在布尔条件语句中调用函数。分配到局部变量并检查它们。
您调用了一个函数，并实质上“丢弃”了结果
2.29三元运算符