这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
关联数组/哈希映射/哈希表(无论它在你最喜欢的语言中叫什么)是自切片面包以来最好的东西!
当然，它们提供了从键到值的快速查找。但它们也使动态构造结构化数据变得容易。在脚本语言中，它通常是表示结构化数据的唯一(至少是最常用的)方法。
恕我直言，它们是许多脚本语言成功的一个非常重要的因素。
甚至在c++中std::map和std::tr1::unordered_map帮助我更快地编写代码。
其他回答
观点:开发者应该测试自己的代码
我曾经见过太多的垃圾交付给测试，但实际上并没有修复问题中的bug，导致了沟通开销，并助长了不负责任的实践。
使用较短的变量名是可以的
但不是嵌套循环中的索引。
.．.“澄清想法”不应该是开发者的唯一责任……是的，XKCD让我用了那个特定的短语…
我们经常会收到一些项目，这些项目都是在伪元类型特定的“代码”中指定的，如果你愿意这样称呼它的话。经常有产品经理为一个项目制定初始需求，并执行接近0%的基本逻辑验证。
我并不是说技术方法不应该由架构师制定，或者具体的实现不应该是开发人员的责任，而是说它应该是产品经理的需求，以确保他们的需求在逻辑上是可行的。
就我个人而言，我参与过太多“简单”的项目，这些项目在这里或那里遇到了一些范围渐变，然后遇到了与之前的需求相矛盾的“小”更改或功能添加——无论是含蓄的还是明确的。在这种情况下，要求做出近乎不可能的改变的人很容易对开发人员无法实现他们的梦想感到愤怒。
编程还处于初级阶段。
尽管编程语言和方法已经发展了很多年，但我们还有很长的路要走。迹象很明显:
语言文档在互联网上随意传播(stackoverflow在这里有所帮助)。 语言在语法上的进化必然会破坏之前的版本。 调试仍然经常使用printf完成。 语言库或其他形式的大规模代码重用仍然相当罕见。
显然，所有这些都在改善，但如果我们都能同意这是开始而不是结束就好了=)。
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()函数/变量名还没有让我失望!
