这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
这是我的:
“你不需要(文本)语法来表达对象及其行为。”
我赞同乔纳森·爱德华兹和他的潜台词项目——http://alarmingdevelopment.org/的观点
其他回答
SESE (Single Entry Single Exit)不是法律
例子:
public int foo() {
if( someCondition ) {
return 0;
}
return -1;
}
vs:
public int foo() {
int returnValue = -1;
if( someCondition ) {
returnValue = 0;
}
return returnValue;
}
我和我的团队发现，在很多情况下，一直遵守这一点实际上会适得其反。
设计模式是石器时代编程语言设计的一个症状
他们有自己的目的。很多优秀的软件都是用它们开发出来的。但事实上，我们需要编写这些心理抽象的“配方”，关于你的代码如何工作/应该如何工作，这说明缺乏足够有表现力的编程语言来为我们处理这种抽象。
补救措施，我认为，在于允许你将越来越多的设计嵌入到代码中的语言，通过定义可能不存在或可能没有普遍适用性，但在你的代码不断处理的情况下真的真的有意义的语言结构。Scheme的人已经知道这一点很多年了，Scheme宏可能会让大多数猴子尿裤子。
开发人员都是不同的，应该被区别对待。
开发者不属于任何一个框框，也不应该被这样对待。解决问题的最佳语言或工具与开发人员的关系与被解决问题的细节关系一样大。
库克的格言随意收集……
The hardest language to learn is your second. The hardest OS to learn is your second one - especially if your first was an IBM mainframe. Once you've learned several seemingly different languages, you finally realize that all programming languages are the same - just minor differences in syntax. Although one can be quite productive and marketable without having learned any assembly, no one will ever have a visceral understanding of computing without it. Debuggers are the final refuge for programmers who don't really know what they're doing in the first place. No OS will ever be stable if it doesn't make use of hardware memory management. Low level systems programming is much, much easier than applications programming. The programmer who has a favorite language is just playing. Write the User's Guide FIRST! Policy and procedure are intended for those who lack the initiative to perform otherwise. (The Contractor's Creed): Tell'em what they need. Give'em what they want. Make sure the check clears. If you don't find programming fun, get out of it or accept that although you may make a living at it, you'll never be more than average. Just as the old farts have to learn the .NET method names, you'll have to learn the library calls. But there's nothing new there. The life of a programmer is one of constantly adapting to different environments, and the more tools you have hung on your belt, the more versatile and marketable you'll be. You may piddle around a bit with little code chunks near the beginning to try out some ideas, but, in general, one doesn't start coding in earnest until you KNOW how the whole program or app is going to be layed out, and you KNOW that the whole thing is going to work EXACTLY as advertised. For most projects with at least some degree of complexity, I generally end up spending 60 to 70 percent of the time up front just percolating ideas. Understand that programming has little to do with language and everything to do with algorithm. All of those nifty geegaws with memorable acronyms that folks have come up with over the years are just different ways of skinning the implementation cat. When you strip away all the OOPiness, RADology, Development Methodology 37, and Best Practice 42, you still have to deal with the basic building blocks of: assignments conditionals iterations control flow I/O
一旦你能真正地把自己包围起来，你最终会到达你想要的那个点 看(从编程的角度来看)编写库存应用程序之间的差别很小 一个汽车零部件公司，一个图形实时TCP性能分析仪，一个数学模型 一个恒星核心，或者一个约会日历。
初级程序员处理小块代码。随着经验的积累， 他们处理越来越大的代码块。 随着经验的增加，他们开始处理小块代码。
大多数编程面试问题都是毫无意义的。尤其是那些由程序员想出的。
这是一种常见的情况，至少根据我和我的朋友的经验，吹牛 程序员，问你一些他花了几周时间在谷歌上搜索的棘手问题。有趣的是，你回到家，一分钟内就把它炸飞了。这就像他们经常试图用他们复杂的武器打败你，而不是检查你是否是一个全面的、务实的团队合作者。
在我看来，类似的愚蠢是当你被要求提供高度可访问的基础知识时，比如:“哦，等等，让我看看你是否可以在一张纸上伪代码insert_name_here-算法(sic!)”。在申请高级编程工作时，我真的需要记住它吗?我应该有效地解决问题或谜题吗?
