这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
每当您向外界公开一个可变类时，您都应该提供事件来观察它的变化。额外的努力也可能说服您最终使其不可更改。
其他回答
你只需要3到5种语言就可以完成所有的事情。C是定的。也许是组装，但你应该知道它，并能使用它。如果你写的是网页代码，可能是javascript和/或Java。一种shell语言(如bash)和一种HLL语言(如Lisp)可能会有用。其他任何事情都会让人分心。
两个人的想法比一个人的好
我坚信结对编程是提高代码质量和编程效率的首要因素。不幸的是，对于那些认为“更多人手=>更多代码=> $$$!”
在编程中使用的进程越多，代码就会变得越糟糕
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.
请阅读文章，了解这些首字母缩写词的解释。
硬编码很好!
真的，在许多情况下更有效，更容易维护!
我看到常数放入参数文件的次数真的非常频繁 你改变了水的冰点还是光速?
对于C程序，只需将这些类型的值硬编码到头文件中，对于java程序，只需将这些值硬编码到静态类中等等。
当这些参数对你的程序行为有巨大的影响时，你真的想对每一个变化做一个回归测试，这似乎是硬编码值更自然。当东西存储在参数/属性文件中时，人们很容易认为“这不是一个程序变更，所以我不需要测试它”。
另一个好处是，它可以防止人们在参数/属性文件中混淆重要值，因为根本没有任何重要值!
Web应用程序糟透了
我的网速很慢。我使用几乎所有不是谷歌的网站的经验至少是令人沮丧的。为什么现在没人写桌面应用了?哦，我明白了。没有人愿意学习操作系统是如何工作的。至少，不是Windows。上次你不得不处理WM_PAINT，你的头爆炸了。创建一个工作线程来执行一个长时间的任务(我的意思是，用Windows的方式来做)完全超出了你的能力。回调是什么鬼?哦，天哪!
垃圾收集糟透了
No, it actually doesn't. But it makes the programmers suck like nothing else. In college, the first language they taught us was Visual Basic (the original one). After that, there was another course where the teachers pretended they taught us C++. But the damage was done. Nobody actually knew how to use this esoteric keyword delete did. After testing our programs, we either got invalid address exceptions or memory leaks. Sometimes, we got both. Among the 1% of my faculty who can actually program, only one who can manage his memory by himself (at least, he pretends) and he's writing this rant. The rest write their programs in VB.NET, which, by definition, is a bad language.
动态类型糟糕透了
当然，除非您正在使用汇编程序(这是一种值得称赞的动态类型)。我的意思是动态解释性语言带来的开销让它们很糟糕。不要用不同的工具适合不同的工作这种愚蠢的论点。C语言是几乎所有事情的正确语言(它快速、强大、可移植)，当它不是(它不够快)时，总有内联汇编。
我可能会提出更多的咆哮，但那将是以后，不是现在。
