这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为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作为脚本语言一样。
其他回答
UML图被高度高估了
当然有一些有用的图，例如复合模式的类图，但是许多UML图是绝对没有价值的。
面向对象编程被过度使用
有时候最好的答案就是简单的答案。
默认情况下，所有变量/属性都应该是只读/final。
这个推理有点类似于Jon提出的类的封闭论证。程序中的一个实体应该有一个任务，而且只有一个任务。特别是，对于大多数变量和属性来说，改变值是绝对没有意义的。基本上有两个例外。
Loop variables. But then, I argue that the variable actually doesn't change value at all. Rather, it goes out of scope at the end of the loop and is re-instantiated in the next turn. Therefore, immutability would work nicely with loop variables and everyone who tries to change a loop variable's value by hand should go straight to hell. Accumulators. For example, imagine the case of summing over the values in an array, or even a list/string that accumulates some information about something else. Today, there are better means to accomplish the same goal. Functional languages have higher-order functions, Python has list comprehension and .NET has LINQ. In all these cases, there is no need for a mutable accumulator / result holder. Consider the special case of string concatenation. In many environments (.NET, Java), strings are actually immutables. Why then allow an assignment to a string variable at all? Much better to use a builder class (i.e. a StringBuilder) all along.
我意识到，今天的大多数语言并没有默认我的愿望。在我看来，由于这个原因，所有这些语言都有根本性的缺陷。如果将它们更改为默认将所有变量视为只读，并且在初始化后不允许对它们进行任何赋值，那么它们的表达性、功能和易用性将不会受到任何损失。
任何足够强大的库都过于复杂而无法使用，而任何足够简单而可用的库都缺乏成为良好通用解决方案所需的功能。
我经常遇到这种情况。穷尽的库，使用起来非常复杂，让我抓狂，简单易用的库，不太能做我需要做的事情。
让您的业务逻辑远离DB。或者至少，保持它非常精简。让DB做它应该做的事情。让代码做它应该做的事情。时期。
If you're a one man show (basically, arrogant & egotistical, not listening to the wisdom of others just because you're in control), do as you wish. I don't believe you're that way since you're asking to begin with. But I've met a few when it comes to this subject and felt the need to specify. If you work with DBA's but do your own DB work, keep clearly defined partitions between your business objects, the gateway between them and the DB, and the DB itself. If you work with DBA's and aren't allowed to do your DB work (either by policy or because they're premadonnas), you're very close to being a fool placing your reliance on them to get anything done by putting code-dependant business logic in your DB entities (sprocs, functions, etc.). If you're a DBA, make developers keep their DB entities clean & lean.
