这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
继承是邪恶的，应该被摈弃。
事实是，在任何情况下，聚合都更好。静态类型的OOP语言不能避免继承，它是描述方法想从类型中得到什么的唯一方法。但是动态语言和鸭子类型可以没有它。Ruby mixins比继承强大得多，也更可控。
其他回答
在编程中使用的进程越多，代码就会变得越糟糕
I have noticed something in my 8 or so years of programming, and it seems ridiculous. It's that the only way to get quality is to employ quality developers, and remove as much process and formality from them as you can. Unit testing, coding standards, code/peer reviews, etc only reduce quality, not increase it. It sounds crazy, because the opposite should be true (more unit testing should lead to better code, great coding standards should lead to more readable code, code reviews should improve the quality of code) but it's not.
我认为这可以归结为我们称之为“软件工程”的事实，而实际上它是设计而不是工程。
以下数字可以证实这一说法:
From the Editor IEEE Software, November/December 2001 Quantifying Soft Factors by Steve McConnell ... Limited Importance of Process Maturity ... In comparing medium-size projects (100,000 lines of code), the one with the worst process will require 1.43 times as much effort as the one with the best process, all other things being equal. In other words, the maximum influence of process maturity on a project’s productivity is 1.43. ... ... What Clark doesn’t emphasize is that for a program of 100,000 lines of code, several human-oriented factors influence productivity more than process does. ... ... The seniority-oriented factors alone (AEXP, LTEX, PEXP) exert an influence of 3.02. The seven personnel-oriented factors collectively (ACAP, AEXP, LTEX, PCAP, PCON, PEXP, and SITE §) exert a staggering influence range of 25.8! This simple fact accounts for much of the reason that non-process-oriented organizations such as Microsoft, Amazon.com, and other entrepreneurial powerhouses can experience industry-leading productivity while seemingly shortchanging process. ... The Bottom Line ... It turns out that trading process sophistication for staff continuity, business domain experience, private offices, and other human-oriented factors is a sound economic tradeoff. Of course, the best organizations achieve high motivation and process sophistication at the same time, and that is the key challenge for any leading software organization.
请阅读文章，了解这些首字母缩写词的解释。
有一次，我从一位同事那里看到了以下内容:
compareto (b) == 0;
我说他不能在一般情况下这样假设，但他只是笑了。
编码不是打字
编写代码需要时间。大多数时候，在编辑器窗口中，您只是查看代码，而不是实际输入。虽然不是经常，但你经常会删除你所写的内容。或者从一个地方搬到另一个地方。或重命名。
如果你长时间敲击键盘，那你一定做错了什么。
推论:每天写的代码行数并不是一个程序员生产力的线性衡量标准，一天写100行的程序员很可能比一天写20行的程序员更好，但一天写5000行的程序员肯定是坏程序员
复制/粘贴不是反模式，事实上它有助于避免产生更多的错误
我的经验法则——只输入不能复制/粘贴的东西。如果创建类似的方法，类或文件-复制现有的并更改所需的内容。(我不是在谈论复制应该放在单个方法中的代码)。
我通常从不输入变量名——要么复制粘贴，要么使用IDE自动补全。如果需要一些DAO方法-复制类似的方法并更改所需的内容(即使将更改90%)。对某些人来说，这可能看起来是极度的懒惰或缺乏知识，但我几乎从来没有处理过由拼写错误引起的问题，而且它们通常很难捕捉(如果没有在编译级别检测到)。
每当我偏离我的复制粘贴规则，开始输入东西时，我总是拼写错误(这只是一个统计数据，没有人能立即写出完美的文本)，然后花更多的时间试图找出哪里。
记录器配置是浪费时间。如果这意味着学习一种新的语法，尤其是一种无声地失败的语法，为什么要有它们呢?不要误解我，我喜欢好的伐木。我喜欢日志记录器的继承和向日志记录器的处理程序添加格式化程序。但是为什么要在配置文件中进行呢?
您希望在不重新编译的情况下对日志代码进行更改吗?为什么?如果您将日志代码放在单独的类、文件中，会有什么不同呢?
您是否希望将可配置的日志与您的产品一起分发给客户端?这不是提供了太多信息吗?
最令人沮丧的是，用流行语言编写的流行实用程序往往会按照该语言指定的格式编写良好的api。编写一个Java日志实用程序，我知道您已经生成了javadocs，我知道如何导航。为您的日志记录器配置编写一种特定于域的语言，我们有什么?也许有文件，但到底哪里去了?你来决定怎么组织，我对你的思路不感兴趣。
