这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
c++是一门很好的语言
一两个星期前，我说c++不是一种很好的语言，在另一个问题上我几乎被私刑了。现在我试着反过来说。；）
不，认真地说，我当时想说的是，c++有很多缺陷，现在我还会再试一次。这一点很难否认。它是如此的复杂，以至于学好它实际上是一件你可以奉献一生的事情。它使许多常见的任务变得不必要的困难，允许用户一头扎进未定义的行为和不可移植的代码的海洋，而编译器没有给出警告。
但它并不是许多人试图创造的那种无用、破旧、过时、令人讨厌的语言。它不应该被掩盖和忽视。没有它，世界不会变得更好。它有一些独特的优势，不幸的是，隐藏在古怪的语法，遗留的麻烦，尤其是糟糕的c++老师背后。但是他们就在那里。
c++有许多我在用c#或其他“现代”语言编程时非常怀念的特性。其中有很多c#和其他现代语言可以学习的地方。
它并没有盲目地专注于OOP，而是探索并开创了泛型编程。它允许惊人地表达编译时元编程，生成极其高效、健壮和干净的代码。在c#出现LINQ或lambda表达式之前，它从函数式编程中吸取了近十年的经验教训。
它允许您通过静态断言和其他元编程技巧在编译时捕获数量惊人的错误，这极大地简化了调试，甚至在某些方面胜过单元测试。(我宁愿在编译时捕获错误，而不是在之后运行测试时捕获错误)。
变量的确定性销毁允许RAII，这是一个非常强大的小技巧，使try/finally块和c#使用块变得多余。
虽然有些人指责它是“由委员会设计的”，但我会说，是的，它是，在这种情况下，这实际上并不是一件坏事。看看Java的类库。又有多少类被弃用了?有多少不应该使用?有多少是相互复制的功能?有多少设计糟糕?
C++'s standard library is much smaller, but on the whole, it's remarkably well designed, and except for one or two minor warts (vector<bool>, for example), its design still holds up very well. When a feature is added to C++ or its standard library, it is subjected to heavy scrutiny. Couldn't Java have benefited from the same? .NET too, although it's younger and was somewhat better designed to begin with, is still accumulating a good handful of classes that are out of sync with reality, or were badly designed to begin with.
c++有很多其他语言无法比拟的优点。这是一门很好的语言
其他回答
我宁愿真正熟练/有经验的老技术，让我有效地解决现实世界的问题，而不是新的“时尚”技术，仍在经历青春期。
C(或c++)应该是第一种编程语言
第一语言不应该是简单的，它应该是建立学生的思想，为严肃的计算机科学做准备的语言。 C语言是完美的，它迫使学生考虑内存和所有低级别的东西，同时他们可以学习如何构造代码(它有函数!)
c++有一个额外的优势，它真的很糟糕:)这样学生就会明白为什么人们必须想出Java和c#
并不是所有东西都需要封装到自己的方法中。有时候让一个方法做不止一件事是可以的。
Having a process that involves code being approved before it is merged onto the main line is a terrible idea. It breeds insecurity and laziness in developers, who, if they knew they could be screwing up dozens of people would be very careful about the changes they make, get lulled into a sense of not having to think about all the possible clients of the code they may be affecting. The person going over the code is less likely to have thought about it as much as the person writing it, so it can actually lead to poorer quality code being checked in... though, yes, it will probably follow all the style guidelines and be well commented :)
不要注释你的代码
注释不是代码，因此当事情发生变化时，不改变解释代码的注释是很容易的。相反，我更喜欢将代码中的垃圾重构到不需要注释的程度。一个例子:
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
