这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
代码中的大多数注释实际上是一种有害的代码复制形式。
我们花了大部分时间维护别人(或者我们自己)写的代码，糟糕的、不正确的、过时的、误导性的注释肯定是代码中最令人讨厌的工件列表的顶部。
我想最终很多人会忘记它们，尤其是那些花盒子里的怪物。
最好集中精力使代码可读，必要时进行重构，并尽量减少习惯用法和奇怪之处。
另一方面，许多课程告诉我们注释几乎比代码本身更重要，这就导致了下面这一行添加了一个注释到invoiceTotal风格。
其他回答
将XML存储在关系数据库中的CLOB中通常是一种可怕的逃避。它不仅在性能方面很糟糕，还将正确管理数据结构的责任从数据库架构师转移到应用程序程序员身上。
不要注释你的代码
注释不是代码，因此当事情发生变化时，不改变解释代码的注释是很容易的。相反，我更喜欢将代码中的垃圾重构到不需要注释的程度。一个例子:
if(data == null) // First time on the page
to:
bool firstTimeOnPage = data == null;
if(firstTimeOnPage)
我唯一一次真正的评论是当它是一个TODO或解释为什么
Widget.GetData(); // only way to grab data, TODO: extract interface or wrapper
如果您的文本编辑器不能很好地完成代码，那么您就是在浪费每个人的时间。
Quickly remembering thousands of argument lists, spellings, and return values (not to mention class structures and similarly complex organizational patterns) is a task computers are good at and people (comparatively) are not. I buy wholeheartedly that slowing yourself down a bit and avoiding the gadget/feature cult is a great way to increase efficiency and avoid bugs, but there is simply no benefit to spending 30 seconds hunting unnecessarily through sourcecode or docs when you could spend nil... especially if you just need a spelling (which is more often than we like to admit).
当然，如果没有为您的语言提供这种功能的编辑器，或者任务简单到足以在加载更重的编辑器所需的时间内完成，那么没有人会告诉您Eclipse和90个插件是正确的工具。但是请不要告诉我，像1999年那样使用H-J-K-L的能力真的比每次需要方法签名时按escape键节省了更多时间……即使你觉得这样做不那么“黑客”了。
想法吗?
如果没有远程调试器，就无法编写web应用程序
Web应用程序通常将客户端和服务器端多种语言之间的交互联系在一起，需要用户进行交互，并且通常包括第三方代码，这些代码可以是简单的API实现，也可以是复杂的框架。
我已经记不清有多少次，当我用一个不错的远程调试器进入并跟踪一个复杂的web应用程序中实际发生的事情时，另一个开发人员坐在我身边，看到他们惊讶地发现有这样的工具存在。通常情况下，即使在看到这些工具的实际运行后，他们仍然不愿意费心安装和设置这些工具。
你只是不能用打印语句调试一个重要的web应用程序。如果应用程序中的所有代码都不正确，则乘以10。
如果您的调试器可以逐步检查所有正在使用的语言，并显示正在发生的http事务，那就更好了。
没有Firebug就无法开发web应用程序
同理，一旦你用过Firebug(或非常接近Firebug的东西)，你就会对那些试图开发web应用程序的人既同情又恐惧。特别是Firebug显示计算样式，如果你还记得不使用它，花了几个小时随机更改各种CSS位，并添加“!重要的”在太多的地方搞笑你永远不会回去。
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()函数/变量名还没有让我失望!
