一般来说，C# 或 .NET Framework 中最大的设计缺陷是什么？
示例：不存在不可为空的字符串类型，从 IDataReader 获取值时必须检查 DBNull。
【问题讨论】：
IEnumerator<T> 上的 Reset() 方法是一个错误（对于迭代器块，语言规范甚至要求这会引发异常）IEnumerable<out T> 和 Func<in T, out TResult>，但不包括具体类型（如 List<T>）添加协变/逆变支持。ApplicationException 相当失宠 - 这是一个错误吗？Contains，然后是 Add），因此同步不同操作的集合是没那么有用
System.Collections.Concurrent types、TryAdd、GetOrAdd、TryRemove 等已在 .NET Framework 4.0 中添加 - 尽管接受工厂委托的方法不保证每个密钥只会调用一次工厂.using/lock 模式——也许允许它们共享可重用（可扩展？）语法；您可以通过返回IDisposable 并使用using 来模拟这一点，但它本来可以更清楚Foo(SqlConnection! connection)（注入空检查/throw）这样的语法会很好（与int?等形成对比）
dynamic 解决了这个问题，或者你可以启用它like this
foreach 扩展中被声明外部，这意味着anon-methods/lambdas 捕获单个变量，而不是每次迭代一个（对于线程/异步/等很痛苦)
【讨论】：
ApplicationException 是一个错误——不像他们希望的那样有用。他们还说System.Exception应该是abstract。
TextWriter 是 StreamWriter 的 base 类。什么鬼？
这总是把我弄糊涂了。
【讨论】：
一个小小的 C# 小毛病 - 构造函数使用 C++/Java 语法，让构造函数与类同名。
New() 或 ctor() 会更好。
当然，诸如 coderush 之类的工具使重命名类的问题不再那么严重，但从可读性 POV 来看，New() 提供了极大的清晰度。
【讨论】：
class Foo { new(int j) {i = j} int i; }
New--大写关键字违反约定），但我不愿称其为设计缺陷。他们想吸引现有的 C++/Java 开发人员，借用许多愚蠢的旧语法约定可以说帮助他们实现了目标。
我非常同意this post（对于那些对缺少 ToString 感到厌烦的人，有一个调试器属性可以为您的类提供自定义格式）。
在上面的列表之上，我还要添加以下合理的要求：
T : new(string)，或T : new(string, int)
var e = new Foo(); e { Bar = baz };
Either<T>”这样的有效封闭代数类型却不是，所以我喜欢某种方式来声明一个封闭代数类型并对其强制执行详尽的模式匹配（基本上是一流的支持对于访问者模式，但效率更高）；所以只需要枚举，用详尽的模式匹配支持扩展它们，并且不允许无效的情况，System.IO 类，如Stream，设计有些糟糕；任何需要一些实现来抛出NotSupportedException 的接口都是糟糕的设计，IList 应该比现在简单得多；事实上，对于许多具体的集合接口来说，这可能是正确的，比如ICollection，INotifyPropertyChanged 等接口的字段和成员名称，这些接口将字段名称作为字符串；您可以通过使用带有MemberExpression 的lambda 的扩展方法来做到这一点，即。 () => Foo，但这不是很有效，
nameof() 运算符，但它在泛型中不起作用（nameof(T) == "T" 而不是实际类型参数的名称：您仍然需要这样做typeof(T).Name）） -它也不允许您获取“路径”字符串，例如nameof(this.ComplexProperty.Value) == "Value" 限制其可能的应用。IArithmetic；其他有用的共享操作界面也是可能的，readonly 关键字，并且 C# 6.0 添加了只读自动属性，但它不像真正的语言对不可变类型和值的支持那么严格。我想这已经足够了。这些都是我在过去一周遇到的所有烦恼。如果我真的全神贯注，我可能会持续几个小时。 C# 4.0 已经添加了命名、可选和默认参数，我非常赞成。
现在提出一个不合理的要求：
漂亮吗？ :-)
【讨论】：
List<T> 的一百万 Ts。您如何建议有效地拍摄快照？ #21：使用readonly 关键字......虽然这里有一些很好的建议，但它们大多只是建议，而不是设计缺陷。我不明白你不能这样做
其中 T : 新（U）
所以你声明泛型类型 T 有一个非默认构造函数。
编辑：
我想这样做：
public class A
{
public A(string text)
{
}
}
public class Gen<T> where T : new(string text)
{
}
【讨论】：
我真的很惊讶我是第一个提到这个的人：
ADO.NET 类型化数据集不会将可空列公开为可空类型的属性。你应该可以这样写：
int? i = myRec.Field;
myRec.Field = null;
相反，你必须写这个，这很愚蠢：
int? i = (int?)myRec.IsFieldNull() ? (int?)null : myRec.Field;
myRec.SetFieldNull();
这在 .NET 2.0 中很烦人，现在更烦人的是，您必须在漂亮整洁的 LINQ 查询中使用像上面这样的 jiggery-pokery。
同样令人讨厌的是，生成的Add<TableName>Row 方法对可空类型的概念同样不敏感。更是如此，因为生成的 TableAdapter 方法不是。
.NET 中并没有太多让我觉得开发团队说“好的，孩子们，我们已经足够接近了 - 发布它！”但这肯定会。
【讨论】：
DBNull.Value 的荒谬之处，而null 本身完全足以表示NULL。幸运的是 LINQ-to-SQL 只是将 null 用于 NULL。
编辑
5. 我的另一个烦恼是 System.Reflection.BindingFlags 如何根据您使用的方法有不同的用途。例如在 FindFields 中 CreateInstance 或 SetField 是什么意思？在这种情况下，他们重载了这个枚举背后的含义，这令人困惑。
【讨论】：
我不知道我会说这是一个设计缺陷，但如果你能像在 VB 中一样推断出 lambda 表达式，那就太好了：
VB：
Dim a = Function(x) x * (x - 1)
C#
如果可以这样做就好了：
var a = x => x * (x - 1);
不必这样做：
Func<int, int> a = x => x * (x - 1);
我意识到它不会再长了，但在 Code Golf 中，每个角色都该死！他们在设计这些编程语言时没有考虑到这一点吗？ :)
【讨论】：
(int x) => x * (x -1); 可以表示Func<int, int>，也可以表示Expression<Func<int, int>>
+ 没有为 object 定义。
Equals 和 GetHashCode - 并非所有类都具有可比性或可散列性，应将其移至接口。会想到 IEquatable 或 IComparable（或类似）。
ToString - 并非所有类都可以转换为字符串，应将其移至接口。我想到了 IFormattable（或类似的）。
泛型应该从一开始就存在：
【讨论】：
EqualityComparer<T>.Default。然后var dict = new Dictionary<object, string>(EqualityComparer<object>.Default) 和var dict = new Dictionary<object, string>() 都将使用参考比较/相等。
EqualityComparer<T>.Default 所做的。无需在每次查找时检查。比较器是Dictionary 实例的一个属性，每个Dictionary 都知道它正在使用哪个。
让我恼火的是Predicate<T> != Func<T, bool> 悖论。它们都是 T -> bool 类型的代表，但它们不兼容分配。
【讨论】：
有些人 (ISV) 希望您可以在构建时将其编译为机器代码并将其链接，以便创建不需要 dotNet 运行时的本机可执行文件。
【讨论】：
我们非常了解正确 OO 技术。解耦、契约式编程、避免不当继承、适当使用异常、开/关主体、Liskov 可替换性等。到目前为止，.Net 框架还没有采用最佳实践。
对我而言，.Net 设计的最大缺陷不是站在巨人的肩膀上；而是站在巨人的肩膀上。 向使用其框架的广大程序员推广不太理想的编程范式。
如果 MS 重视这一点，软件工程界在这十年中本可以在质量、稳定性和可扩展性方面取得巨大飞跃，但可惜，它似乎正在倒退。
【讨论】：
我不喜欢 C# switch 语句。
我想要这样的东西
switch (a) {
1 : do_something;
2 : do_something_else;
3,4 : do_something_different;
else : do_something_weird;
}
所以没有更多的中断（容易忘记）并且可以用逗号分隔不同的值。
【讨论】：
switch 在所有模仿 C 故意残废版本的语言（针对速度进行了优化！）中都被彻底破坏了。 VB 的表现要好得多，但仍然落后于具有模式匹配的语言（Haskell、F# ...）。
C# 中的事件，您必须显式检查侦听器。这难道不是事件的重点，向碰巧在那里的任何人广播吗？就算没有？
【讨论】：
嵌套/递归iterators 的糟糕（并且对大多数人来说完全不可见）O(N^2) 行为。
我很失望他们知道这件事，知道how to fix it，但它没有被视为具有足够的优先级来值得纳入。
我一直在使用类似树的结构，当聪明人无意中以这种方式引入高成本操作时，我不得不纠正他们的代码。
“yield foreach”的美妙之处在于，更简单、更容易的语法鼓励正确、高性能的代码。这是我认为他们在添加新功能以使平台长期成功之前应该追求的"pit of success"。
【讨论】：
有些类实现了接口，但它们没有实现该接口的许多方法，例如 Array 实现了 IList 但 9 个方法中有 4 个抛出 NotSupportedException http://msdn.microsoft.com/en-us/library/system.array_members.aspx
【讨论】：
接口中的静态成员和嵌套类型。
当接口成员具有特定于接口的类型的参数（例如 enum）时，这特别有用。将枚举类型嵌套在接口类型中会很好。
【讨论】：
事件的非常危险的默认性质。由于订阅者被删除，您可以调用事件并处于不一致的状态，这真是太可怕了。有关该主题的更多信息，请参阅 Jon Skeet's 和 Eric Lippert's 优秀文章。
【讨论】：
null 无处不在。
const 无处。
API 不一致，例如对数组进行变异会返回 void，但附加到 StringBuffer 会返回相同的可变 StringBuffer。
集合接口与不可变数据结构不兼容，例如System.Collections.Generic.IList<_> 中的 Add 无法返回结果。
没有结构类型，所以你写System.Windows.Media.Effects.SamplingMode.Bilinear而不是Bilinear。
由类实现的可变IEnumerator接口应该是不可变struct。
System.Collections.Generic.IComparer 和 System.Collections.Generic.IEqualityComparer。
元组应该是结构，但结构不必要地抑制尾调用消除，因此最常见和基本的数据类型之一将不必要地分配并破坏可扩展的并行性。
【讨论】：
IEnumerator？
0 兼职作为枚举
枚举的特性：http://blogs.msdn.com/abhinaba/archive/2007/01/09/more-peculiarites-of-enum.aspx
正如这个很好的例子所示： http://plus.kaist.ac.kr/~shoh/postgresql/Npgsql/apidocs/Npgsql.NpgsqlParameterCollection.Add_overload_3.html
我的建议，好好利用“@”符号：
代替：
如果 ((myVar & MyEnumName.ColorRed) != 0)
使用这个：
如果 ((myVar & MyEnumName.ColorRed) != @0)
【讨论】：
要添加到其他人已经提出的长长的优点列表中：
DateTime.Now == DateTime.Now 在大多数情况下，但不是所有情况。
String 是不可变的，有很多构造和操作选项，但 StringBuilder（可变）没有。
Monitor.Enter 和 Monitor.Exit 应该是实例方法，因此您可以新建一个 Monitor 并锁定它，而不是新建一个特定对象进行锁定。
析构函数不应该被命名为析构函数。 ECMA 规范称它们为终结器，这对 C++ 人群来说不那么容易混淆，但语言规范仍然将它们称为析构函数。
【讨论】：
DateTime.Now 是世界上最明显的竞争条件，但其他条件 +1
我们使用属性的方式有时会激怒我。我喜欢将它们视为 Java 的 getFoo() 和 setFoo() 方法的等价物。但他们不是。
如果Property Usage Guidelines 声明属性应该能够以任何顺序设置以便序列化可以工作，那么它们对于设置器时间验证毫无用处。如果您的背景是您希望防止对象允许自己进入无效状态，那么属性不是您的解决方案。有时我看不到他们比公共成员更好，因为我们在属性中应该做的事情非常有限。
为此，我一直希望（这主要是在这里大声思考，我只是希望我能做这样的事情）我可以以某种方式扩展属性语法。想象一下这样的事情：
private string password;
public string Password
{
// Called when being set by a deserializer or a persistence
// framework
deserialize
{
// I could put some backward-compat hacks in here. Like
// weak passwords are grandfathered in without blowing up
this.password = value;
}
get
{
if (Thread.CurrentPrincipal.IsInRole("Administrator"))
{
return this.password;
}
else
{
throw new PermissionException();
}
}
set
{
if (MeetsPasswordRequirements(value))
{
throw new BlahException();
}
this.password = value;
}
serialize
{
return this.password;
}
}
我不确定这是否有用或访问这些会是什么样子。但我只是希望我可以对属性做更多的事情，并真正将它们视为 get 和 set 方法。
【讨论】：
扩展方法很好，但它们是解决问题的一种丑陋的方法，这些问题本来可以用真正的 mixins 更干净地解决（看看 ruby 看看我在说什么），关于 mixins 的主题。将它们添加到语言中的一个非常好的方法是允许使用泛型进行继承。这允许您以一种很好的面向对象的方式扩展现有类：
public class MyMixin<T> : T
{
// etc...
}
这可以像这样用来扩展一个字符串，例如：
var newMixin = new MyMixin<string>();
它比扩展方法强大得多，因为它允许您覆盖方法，例如将它们包装起来，从而允许在语言中实现类似 AOP 的功能。
对不起，我的咆哮:-)
【讨论】：
能够调用扩展 空变量上的方法是有争议的 例如
对象 a=null; a.MyExtMethod(); // 这是可调用的，假设它在某个地方定义了 MyExtMethod
它可能很方便，但在空引用异常主题上是模棱两可的。
一个命名“缺陷”。 System.configuration.dll 中“配置”的“C”应大写。
异常处理。应该像在 Java 中一样强制捕获或抛出异常，编译器应该在编译时检查它。用户不应依赖 cmets 获取目标调用中的异常信息。
【讨论】：
框架 V1 中 SqlCommand 上的 .Parameters.Add() 方法设计得很糟糕——如果你传入一个值 (int) 为 0 的参数，其中一个重载基本上不起作用——这导致给他们在 SqlCommand 类上创建 .Parameters.AddWithValue() 方法。
【讨论】：
ICollection<T> 和IList<T> 的子集；至少，协变只读集合接口 IListSource<out T>（带有枚举器、索引器和计数）会非常有用。Transform(Sequence<T>, Func<T,T>) 函数，该函数需要快速确定该函数是返回相同的值还是不同的值。如果函数不修改其大部分/所有参数，则输出序列可以共享来自输入序列的部分/全部内存。如果无法按位比较任何值类型 T，则必须使用慢得多的比较，这会极大地损害性能。List<T> 转换为假设的IListSource<U>（其中 T:U）。至少有 three different libraries （独立编写）来提供此功能（当然存在性能缺陷——如果可以找到完美的解决方法，将其称为 .网）。WeakReference<T>（您可以轻松编写自己的，但它会在内部使用强制转换。）Predicate<T> 与Func<T,bool>），相同的委托类型被认为是不兼容的（没有隐式转换）这一事实对我来说是一件麻烦事。我经常希望我们可以将structural typing 用于接口和委托，以实现组件之间更松散的耦合，因为在.NET 中，独立 DLL 中的类实现相同的接口是不够的——它们还必须共享对第三个定义接口的 DLL。DBNull.Value 存在，即使 null 也同样可以起到同样的作用。variable = variable ?? value。事实上，C# 中有一些地方不必要地缺乏对称性。例如你可以写if (x) y(); else z();（不带大括号），但你不能写try y(); finally z();。【讨论】：
IList<T> 的子集，尽管我会使用IReadableByIndex<out T> 和IAppendable<in T>。你的许多其他事情我也同意。
IListReader<T> 上妥协 ;) - 我使用“源”这个词作为“接收器”的反义词（只写接口）。
IListSource<in T> 或IReadableList<out T>。让基本接口类型包含并非在所有派生中都存在的方法是有价值的，尽管我认为让接口有些专门化通常是件好事。例如，可以有一个IList<T>，其中包含可能起作用或可能不起作用的调整大小的方法，以及一个实现相同方法但保证它们应该起作用的IResizableList<T>。这种方法在字段可能包含对可变列表的唯一现有引用或对不可变列表的共享引用的情况下可能很有用。
if (rl:(list as IResizableList<T>) != null) rl.Add(...);，但还有其他建议。作为各种集合和集合适配器的作者，让我厌烦的是编写了许多抛出异常的伪方法。作为一个类型安全爱好者，我不想被允许调用非法方法。一个 IntelliSense 粉丝，我不想看到他们列出来。
在 1.x 中让我印象深刻的一件事是在使用 System.Xml.XmlValidatingReader 时，ValidationEventHandler 的 ValidationEventArgs 不会暴露底层的 XmlSchemaException（标记为内部），其中包含所有有用的信息，例如linenumber 和 position。相反，您应该从 Message 字符串属性中解析它或使用反射来挖掘它。当您想向最终用户返回更经过清理的错误时，效果就不太好了。
【讨论】：
不喜欢你不能在另一个枚举中使用一个枚举的值，例如：
enum Colors { white, blue, green, red, black, yellow }
enum SpecialColors { Colors.blue, Colors.red, Colors.Yellow }
【讨论】：
typeof(Color) != typeof(SpecialColors).
enum SpecialColors { blue = Colors.blue, red = Colors.red, yellow = Colors.Yellow }
IMO 的隐式类型变量实施得很差。我知道你真的应该只在使用 Linq 表达式时使用它们，但是你不能在本地范围之外声明它们很烦人。
来自 MSDN：
我认为这是一个糟糕的实现的原因是他们称它为 var，但它距离变体还有很长的路要走。它实际上只是不必输入完整类名的简写语法（与 Linq 一起使用时除外）
【讨论】：