这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
编程既不是艺术也不是科学。这是一门工程学科。
这不是艺术:编程当然需要创造力。这并不能让它成为艺术。代码的设计和编写是为了正常工作，而不是为了情感上的感动。除了空格之外，出于美观原因更改代码会破坏代码。虽然代码可以很漂亮，但艺术不是主要目的。
这不是科学:科学和技术是不可分割的，但编程属于技术范畴。编程不是系统的学习和观察;它是设计和实现。
这是一门工程学科:程序员设计和构建东西。优秀的程序员为功能而设计。他们了解不同实现选项的利弊，并选择适合他们正在解决的问题的实现选项。
我敢肯定有些人喜欢解析文字，将艺术和科学的定义扩展到包括编程，或将工程限制为机械机器或硬件。查字典。此外，“计算机编程艺术”是艺术的另一种用法，指的是一种技能或工艺，如“对话的艺术”。编程的产物不是艺术。
其他回答
WordPress是一个CMS(从技术上讲，确实如此)。
https://stackoverflow.com/questions/105648/wordpress-is-it-a-cms
没有“放之四海而皆准”的发展方法
我很惊讶这是一个有争议的观点，因为在我看来这是常识。然而，在热门博客上有许多文章都在推广“一刀切”的开发方法，所以我认为我可能只是少数。
我所见过的被吹捧为任何项目的正确方法的东西——在了解任何关于它的信息之前——像使用测试驱动开发(TDD)、领域驱动设计(DDD)、对象关系映射(ORM)、敏捷(大A)、面向对象(OO)等等，等等，包括从方法到架构到组件的一切。当然，这些都是很有市场价值的首字母缩写。
人们甚至似乎在他们的博客上贴上徽章，比如“我是测试驱动的”或类似的东西，就好像他们严格坚持单一的方法，不管项目的细节是什么，实际上是一件好事。
它不是。
选择正确的方法、体系结构和组件，等等，是应该在每个项目的基础上完成的事情，不仅取决于您正在从事的项目的类型及其独特的需求，而且还取决于与您一起工作的团队的规模和能力。
Xah Lee: actually has some pretty noteworthy and legitimate viewpoints if you can filter out all the invective, and rationally evaluate statements without agreeing (or disagreeing) based solely on the personality behind the statements. A lot of my "controversial" viewpoints have been echoed by him, and other notorious "trolls" who have criticized languages or tools I use(d) on a regular basis. [Documentation Generators](http://en.wikipedia.or /wiki/Comparison_of_documentation_generators): ... the kind where the creator invented some custom-made especially-for-documenting-sourcecode roll-your-own syntax (including, but not limited to JavaDoc) are totally superfluous and a waste of time because: 1) They are underused by the people who should be using them the most; and 2) All of these mini-documentation-languages all of them could easily be replaced with YAML
(未命名)元组是邪恶的
如果您使用元组作为具有唯一含义的多个对象的容器，请改用类。 如果您使用它们来保存几个应该通过索引访问的对象，请使用列表。 如果您使用它们从一个方法中返回多个值，请使用Out参数(这需要您的语言支持引用传递) 如果这是代码混淆策略的一部分，那就继续使用它们!
我看到人们使用元组只是因为他们懒得给他们的对象命名。API的用户将被迫基于无意义的索引(而不是有用的名称)访问元组中的项。
绝大多数正在开发的软件在收集需求时不涉及最终用户。
通常只是一些经理提供“需求”。
