这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
不是真正的编程，但我不能忍受css只布局只是为了它。它会适得其反，令人沮丧，并且使维护成为浮动和页边距的噩梦，因为改变单个元素的位置可能会使整个页面混乱。
这绝对不是一个流行的观点，但我在20分钟内就完成了我的表格布局，而css专家们花了几个小时调整行高、页边距、填充和浮动，只是为了做一些基本的事情，如垂直对齐一个段落。
其他回答
绝大多数正在开发的软件在收集需求时不涉及最终用户。
通常只是一些经理提供“需求”。
异常应该只在真正异常的情况下使用
在我最近参与的项目中，异常的使用似乎非常猖獗。
这里有一个例子:
我们有拦截网络请求的过滤器。筛选器调用筛选器，筛选器的任务是检查请求是否具有某些输入参数并验证这些参数。你设置了要检查的字段，并且抽象类确保参数不为空，然后调用一个由你的特定类实现的screen()方法来进行更多的扩展验证:
public boolean processScreener(HttpServletRequest req, HttpServletResponse resp, FilterConfig filterConfig) throws Exception{
//
if (!checkFieldExistence(req)){
return false;
}
return screen(req,resp,filterConfig);
}
checkFieldExistance(req)方法从不返回false。如果所有字段都不缺少，则返回true，如果缺少字段则抛出异常。
我知道这是一种糟糕的设计，但部分问题在于，这里的一些架构师认为，每次遇到意外情况时都需要抛出异常。
此外，我知道checkFieldExistance(req)的签名确实抛出了一个异常，这只是我们几乎所有的方法都这样做-所以我没有想到这个方法可能会抛出一个异常而不是返回false。直到我翻遍代码才发现。
默认情况下，所有变量/属性都应该是只读/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.
我意识到，今天的大多数语言并没有默认我的愿望。在我看来，由于这个原因，所有这些语言都有根本性的缺陷。如果将它们更改为默认将所有变量视为只读，并且在初始化后不允许对它们进行任何赋值，那么它们的表达性、功能和易用性将不会受到任何损失。
我不明白为什么人们认为Java绝对是大学里最好的“首选”编程语言。
首先，我认为第一种编程语言应该强调学习控制流和变量的必要性，而不是对象和语法
另一方面，我相信没有在C / c++中调试内存泄漏经验的人无法完全理解Java带来的好处。
同样，自然的进展应该是从“我怎么能做这个”到“我怎么能找到做那个的库”，而不是相反。
我坚信非托管代码不值得这么麻烦。与查找内存泄漏相关的额外维护性开销(即使是最好的程序员偶尔也会引入这种开销)远远超过从c++这样的语言获得的性能。如果Java, c#等不能得到你需要的性能，买更多的机器。
