这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
将单元测试作为验证代码的最后手段。
如果你想验证代码是正确的，我更喜欢以下技术而不是单元测试:
类型检查 断言 简单可验证的代码
对于其他一切，都有单元测试。
其他回答
我曾经因为在公共场合发表这些观点而受到批评，但现在我要说的是:
动态类型语言中编写良好的代码遵循静态类型约定
在使用过Python、PHP、Perl和其他一些动态类型语言之后，我发现用这些语言编写的良好代码遵循静态类型约定，例如:
Its considered bad style to re-use a variable with different types (for example, its bad style to take a list variable and assign an int, then assign the variable a bool in the same method). Well-written code in dynamically typed languages doesn't mix types. A type-error in a statically typed language is still a type-error in a dynamically typed language. Functions are generally designed to operate on a single datatype at a time, so that a function which accepts a parameter of type T can only sensibly be used with objects of type T or subclasses of T. Functions designed to operator on many different datatypes are written in a way that constrains parameters to a well-defined interface. In general terms, if two objects of types A and B perform a similar function, but aren't subclasses of one another, then they almost certainly implement the same interface.
虽然动态类型语言当然提供了不止一种解决难题的方法，但这些语言中大多数编写良好的惯用代码都密切关注类型，就像用静态类型语言编写的代码一样严格。
动态类型并不会减少程序员需要编写的代码量
When I point out how peculiar it is that so many static-typing conventions cross over into dynamic typing world, I usually add "so why use dynamically typed languages to begin with?". The immediate response is something along the lines of being able to write more terse, expressive code, because dynamic typing allows programmers to omit type annotations and explicitly defined interfaces. However, I think the most popular statically typed languages, such as C#, Java, and Delphi, are bulky by design, not as a result of their type systems.
我喜欢使用带有真正类型系统的语言，比如OCaml，它不仅是静态类型，而且它的类型推断和结构类型允许程序员省略大多数类型注释和接口定义。
ML语言家族的存在表明，我们可以享受静态类型的好处，同时也享受动态类型语言的简洁。实际上，我使用OCaml的REPL来编写临时的、一次性的脚本，就像其他人使用Perl或Python作为脚本语言一样。
所有源代码和注释都应该用英文编写
用英语以外的语言编写源代码和/或注释会降低可重用性，如果你不理解它们所使用的语言，就更难调试。
SQL表、视图和列也是如此，特别是在使用缩写时。如果它们没有缩写，我可能能够在线翻译表/列名，但如果它们被缩写，我所能做的就是选择并尝试破译结果。
我也认为在源代码控制中使用二进制文件并没有什么错。如果有充分的理由的话。如果我有一个程序集，我没有源代码，并且可能不一定在每个devs机器上的相同位置，那么我通常会将它放在“二进制”目录中，并使用相对路径在项目中引用它。
相当多的人似乎认为我应该被烧死在火刑柱上，因为我甚至在同一个句子中提到了“源代码控制”和“二进制”。我甚至知道一些地方有严格的规定，说你不能添加它们。
我坚信非托管代码不值得这么麻烦。与查找内存泄漏相关的额外维护性开销(即使是最好的程序员偶尔也会引入这种开销)远远超过从c++这样的语言获得的性能。如果Java, c#等不能得到你需要的性能，买更多的机器。
观点:SQL是代码。这样对待它
也就是说，就像c#、Java或其他喜欢的对象/过程语言一样，开发一种可读且可维护的格式化样式。
我讨厌看到草率的自由格式SQL代码。如果您在页面上看到两种样式的花括号时都尖叫，那么当您看到自由格式化的SQL或模糊JOIN条件的SQL时，为什么不尖叫呢?
