这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
我也认为在源代码控制中使用二进制文件并没有什么错。如果有充分的理由的话。如果我有一个程序集，我没有源代码，并且可能不一定在每个devs机器上的相同位置，那么我通常会将它放在“二进制”目录中，并使用相对路径在项目中引用它。
相当多的人似乎认为我应该被烧死在火刑柱上，因为我甚至在同一个句子中提到了“源代码控制”和“二进制”。我甚至知道一些地方有严格的规定，说你不能添加它们。
其他回答
That (at least during initial design), every Database Table (well, almost every one) should be clearly defined to contain some clearly understanable business entity or system-level domain abstraction, and that whether or not you use it as a a primary key and as Foreign Keys in other dependant tables, some column (attribute) or subset of the table attributes should be clearly defined to represent a unique key for that table (entity/abstraction). This is the only way to ensure that the overall table structure represents a logically consistent representation of the complete system data structure, without overlap or misunbderstood flattening. I am a firm believeer in using non-meaningful surrogate keys for Pks and Fks and join functionality, (for performance, ease of use, and other reasons), but I beleive the tendency in this direction has taken the database community too far away from the original Cobb principles, and we jhave lost much of the benefits (of database consistency) that natural keys provided.
那么为什么不两者都用呢?
使用较短的变量名是可以的
但不是嵌套循环中的索引。
只有一种设计模式:封装
例如:
工厂方法:您已经封装了对象创建 策略:封装了不同的可变算法 迭代器:您封装了按顺序访问集合中的元素的方法。
在. net上开发不是编程。它只是把其他人的代码拼接在一起。
我的编码背景要求你了解硬件，这在我的行业中仍然是一个至关重要的要求，我认为高级语言只是简单地组装别人的工作。这并没有什么本质上的错误，但这是“编程”吗?
微软在为“开发人员”提供符号指令语法方面做了很多艰苦的工作。我现在似乎认识了越来越多的开发人员，他们在执行工作时似乎受到类的存在或不存在的限制。
我的观点来自于这样一个概念:作为一名程序员，你应该能够在你的平台允许的最低水平上编程。因此，如果您正在编写。net程序，那么您需要能够埋头苦干并找出解决方案，而不是依赖于其他人为您创建一个类。在我看来，这是一种懒惰，不符合“发展”的标准。
德尔菲很有趣
是的，我知道它已经过时了，但是Delphi是一个非常有趣的开发工具。
