这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
学校教育毁掉创造力
*“废墟”指“潜在的废墟”
当然，上学是需要的!每个人在使用之前都需要学习一些东西——然而，如果我们不小心的话，你所有关于如何为特定的业务领域采取某种策略的伟大想法都很容易被扔进我们的大脑深处。
当你学习新事物、获得新技能时，你也会把自己的思维定势限制在这些新事物和新技能上，因为它们显然是“做事的方法”。作为人类，我们倾向于听从权威——无论是老师、顾问、同事，甚至是你喜欢的网站/论坛。我们应该时刻注意我们思维运作的“缺陷”。听别人说什么，但不要认为他们说的是理所当然的。对你收到的每一个新信息都要保持一种批判的观点。
而不是想“哇，这很聪明。我从现在开始就用它了”，我们应该想“哇，这很聪明。现在，我如何在我的个人技能和想法的工具箱中使用它?”
其他回答
Variable_Names_With_Bloody_Underscores
或者更糟
CAPITALIZED_VARIABLE_NAMES_WITH_BLOODY_UNDERSCORES
应该在全球范围内清除……与偏见!CamelCapsAreJustFine。 (全局常数不承受)
GOTO语句仅供11岁以下的开发人员使用
任何不支持指针的语言都名不副实
.Net = .Bloat 微软网站开发的最佳范例(无表情web 2) 是缓慢膨胀的最好的例子cr@pw@re曾经写过。 (可以试试Web Studio)
回应: 好的，让我来谈谈下划线的问题。从你提供的C链接:
-全局常量应该全部大写，用“_”分隔符。 我实际上同意这一点，因为这太明显了
-以NetworkABCKey为例。注意ABC中的C和调音中的K是如何混淆的。有些人不介意这一点，有些人只是讨厌它，所以你会在不同的代码中发现不同的策略，所以你永远不知道该如何调用某个东西。
我属于前者。我选择名字非常谨慎，如果你不能一眼看出K属于Key，那么英语可能不是你的第一语言。
C函数名 在c++项目中应该有很少的C函数。 对于C函数，使用GNU约定的所有小写字母，以'_'作为单词分隔符。
的理由
* It makes C functions very different from any C++ related names.
例子
int some_bloody_function () ｛ ｝
这些“标准”和惯例只不过是随时间而传下来的任意决定。我认为，虽然它们有一定的逻辑意义，但它们使代码变得混乱，使一些本应简短而易于阅读的东西变得笨拙、冗长和混乱。
C被采纳为事实上的标准，不是因为它友好，而是因为它无处不在。我可以用一种语法友好的高级语言用20行代码编写100行C代码。
这使得程序流易于阅读，并且我们都知道，在一年或更长时间后重新访问代码意味着要到处跟踪面包屑。
我确实使用下划线，但只对全局变量，因为它们很少，而且它们很明显。除此之外，一个经过深思熟虑的CamelCaps()函数/变量名还没有让我失望!
设计模式是石器时代编程语言设计的一个症状
他们有自己的目的。很多优秀的软件都是用它们开发出来的。但事实上，我们需要编写这些心理抽象的“配方”，关于你的代码如何工作/应该如何工作，这说明缺乏足够有表现力的编程语言来为我们处理这种抽象。
补救措施，我认为，在于允许你将越来越多的设计嵌入到代码中的语言，通过定义可能不存在或可能没有普遍适用性，但在你的代码不断处理的情况下真的真的有意义的语言结构。Scheme的人已经知道这一点很多年了，Scheme宏可能会让大多数猴子尿裤子。
根据我得到的大量反馈，我最具争议的观点显然是，程序员并不总是读他们声称读过的书。这紧跟着我的观点，一个受过正规教育的程序员比一个自学成才的程序员更好(但不一定比另一个自学成才的程序员更好)。
像SharePoint这样的内部网框架让我觉得整个企业世界是一只把头埋在沙子里的巨大鸵鸟
我在这里不仅仅是在谈论MOSS，我也使用过一些其他的企业内部网产品，绝对没有一个是好的，但是SharePoint (MOSS)是目前为止最差的。
Most of these systems don't easily bridge the gap between Intranet and Internet. So as a remote worker you're forced to VPN in. External customers just don't have the luxury of getting hold of your internal information first hand. Sure this can be fixed at a price $$$. The search capabilities are always pathetic. Lots of time other departments simply don't know about information is out there. Information fragments, people start boycotting workflows or revert to email SharePoint development is the most painful form of development on the planet. Nothing sucks like SharePoint. I've seen a few developers contemplating quitting IT after working for over a year with MOSS. No matter how the developers hate MOSS, no matter how long the most basic of projects take to roll out, no matter how novice the results look, and no matter how unsearchable and fragmented the content is:
每个人仍然在继续使用和购买sharepoint，经理们仍然非常努力地假装它不是撒旦的产物。
微格式
Using CSS classes originally designed for visual layout - now being assigned for both visual and contextual data is a hack, loads of ambiguity. Not saying the functionality should not exist, but fix the damn base language. HTML wasn't hacked to produce XML - instead the XML language emerged. Now we have these eager script kiddies hacking HTML and CSS to do something it wasn't designed to do, thats still fine, but I wish they would keep these things to themselves, and no make a standard out of it. Just to some up - butchery!
如果你想写出好的软件，那就离开你的电脑
去和最终用户以及想要和需要软件的人一起玩。只有从他们那里，你才能理解你的软件需要完成什么以及它需要如何完成。
询问他们对现有流程的爱与恨。 向他们询问他们的流程的未来，它的方向是什么。 出去逛逛，看看他们现在在用什么，弄清楚他们的使用模式。您需要满足并匹配他们的使用期望。看看他们还经常使用什么，特别是如果他们喜欢它并且可以有效地使用它。匹配。
最终用户根本不在乎你的代码有多优雅，也不在乎用什么语言写的。如果它对他们有效，他们喜欢使用它，你就赢了。如果它不能让他们的生活更轻松和更好——他们讨厌它，你就输了。
站在他们的立场上走一英里，然后去写你的代码。
