这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
开发80%是关于设计，20%是关于编码
我认为开发者应该将80%的时间用于设计细节，即他们将要构建的内容，而只有20%的时间用于编写他们所设计的内容。这将产生几乎零错误的代码，并在测试-修复-重新测试周期中节省大量时间。
过早地进入金属(或IDE)就像过早的优化，这被认为是万恶之源。深思熟虑的前期设计(我说的不一定是庞大的设计文档，简单的白板图纸也可以)会比编码和修改产生更好的结果。
其他回答
如果语言已经公开了实际类型，就不要为基本类型使用关键字。在c#中，这将指bool (Boolean)， int (Int32)， float (Single)， long (Int64)。'int'， 'bool'等不是语言的实际部分，而只是实际类型的'快捷方式'或'别名'。不要使用不存在的东西!在我看来，Int16, Int32, Int64，布尔值等比'short'， 'long'， 'int'更有意义。
从长远来看，开源软件的成本更高
对于常规的业务公司来说，开源看起来是免费的，但隐藏着成本。
当你考虑到质量的不一致性，可变的可用性和UI/UX，互操作性和标准的困难，增加的配置，相关的培训和支持需求的增加，开源的总拥有成本要比商业产品高得多。
精通技术的程序员类型接受开源的解放并与之一起运行;他们“得到它”，可以采用它，并定制它，以满足他们的目的。另一方面，主要是非技术性的，但需要软件来运行他们的办公室、网络和网站的企业正在冒着痛苦的风险，并在时间损失、生产力和(最终)支持费用方面付出沉重的代价，以及/或一起放弃实验的成本。
可用性问题从来不是用户的错。
当某些用户做了一些团队中所有人都认为“只是一件愚蠢的事情”时，我无法计算问题出现的频率。像“为什么有人要这么做?”或者“为什么他不做XYZ”这样的短语经常出现。
尽管许多人已经厌倦了听我说:如果一个现实生活中的用户试图做一些事情，要么没有工作，导致一些错误或导致意想不到的行为，那么这可能是任何人的错，而不是用户的错!
请注意，我不是指那些故意滥用软件的人。我指的是软件的假定目标组。
布尔变量只能用于布尔逻辑。在所有其他情况下，使用枚举。
布尔变量用于存储只能有两个可能值的数据。使用它们所产生的问题经常被忽视:
程序员通常不能正确地识别某些数据何时应该只有两个可能的值 指导程序员做什么的人，比如程序经理或编写程序员遵循的规范的人，通常也不能正确地识别这一点 即使一段数据被正确地识别为只有两种可能的状态，这种保证在将来也可能不成立。
在这些情况下，使用布尔变量会导致令人困惑的代码，这通常可以通过使用枚举来避免。
例子
假设一个程序员正在为一家只销售轿车和卡车的汽车经销商编写软件。程序员为他的软件开发一个全面的业务需求模型。由于知道所销售的车辆只有轿车和卡车两种类型，他正确地识别出可以在Vehicle类中使用一个布尔变量来指示车辆是轿车还是卡车。
class Vehicle {
bool isTruck;
...
}
这个软件是这样写的，当isTruck为真时，车辆是一辆卡车，当isTruck为假时，车辆是一辆汽车。这是在整个代码中执行多次的简单检查。
一切都很顺利，直到有一天，汽车经销商收购了另一家同样销售摩托车的经销商。程序员必须更新软件，使其能够正确地考虑到经销商的业务发生了变化。现在它需要识别车辆是汽车、卡车还是摩托车，这是三种可能的状态。
程序员应该如何实现这一点?isTruck是一个布尔变量，所以它只能保存两种状态。他可以将其从布尔类型更改为允许多种状态的其他类型，但这将破坏现有的逻辑，并且可能无法向后兼容。从程序员的角度来看，最简单的解决方案是添加一个新变量来表示车辆是否是摩托车。
class Vehicle {
bool isTruck;
bool isMotorcycle;
...
}
代码更改后，当isTruck为真时，车辆为卡车，当isMotorcycle为真时，车辆为摩托车，当两者都为假时，车辆为汽车。
问题
这种解决方案存在两个大问题:
The programmer wants to express the type of the vehicle, which is one idea, but the solution uses two variables to do so. Someone unfamiliar with the code will have a harder time understanding the semantics of these variables than if the programmer had used just one variable that specifies the type entirely. Solving this motorcycle problem by adding a new boolean doesn't make it any easier for the programmer to deal with such situations that happen in the future. If the dealership starts selling buses, the programmer will have to repeat all these steps over again by adding yet another boolean.
软件的业务需求发生变化，要求他修改现有代码，这不是开发人员的错。但是首先使用布尔变量使得他的代码不那么灵活，也更难修改以满足未知的未来需求(不那么“适合未来”)。当他以最快的方式实现更改时，代码变得难以阅读。使用布尔变量最终是一个不成熟的优化。
解决方案
首先使用枚举就可以避免这些问题。
enum EVehicleType { Truck, Car }
class Vehicle {
EVehicleType type;
...
}
为了在这种情况下容纳摩托车，程序员所要做的就是将Motorcycle添加到evhicletype中，并添加新的逻辑来处理摩托车的情况。不需要添加新的变量。现有的逻辑不应该被打乱。不熟悉代码的人也很容易理解车辆的类型是如何存储的。
悬崖笔记
不要使用只能存储两种不同状态的类型，除非您绝对确定两种状态总是足够的。如果将来可能需要两个以上的状态，则使用枚举，即使布尔值可以满足现有需求。
如果不值得测试，就不值得构建
