这绝对是主观的,但我想尽量避免它变成争论。我认为如果人们恰当地对待它,这将是一个有趣的问题。

这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上,但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。

那么,你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如,大括号放置),但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。

请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点,不管你是否恰好同意这些观点。


当前回答

对于一个优秀的程序员来说,语言不是问题。

这可能不是很有争议,但我听到很多其他程序员的抱怨,比如“为什么他们不都用delphi?”,“c#糟透了”,“如果他们强迫我用java,我就会换公司”等等。 我所认为的是,一个好的程序员是灵活的,能够用他一生中可能不得不学习的任何编程语言编写好的程序

其他回答

编程还处于初级阶段。

尽管编程语言和方法已经发展了很多年,但我们还有很长的路要走。迹象很明显:

语言文档在互联网上随意传播(stackoverflow在这里有所帮助)。 语言在语法上的进化必然会破坏之前的版本。 调试仍然经常使用printf完成。 语言库或其他形式的大规模代码重用仍然相当罕见。

显然,所有这些都在改善,但如果我们都能同意这是开始而不是结束就好了=)。

生成的文档几乎总是毫无价值的。

或者,作为一个推论:您的API需要为维护者和用户提供单独的文档集。

实际上有两类人需要了解您的API:维护者,他们必须了解您的实现的细节,以便有效地完成工作;用户,他们需要高级的概述、示例和关于他们所访问的每个方法的效果的详细细节。

我从未遇到过在这两个方面都成功的生成文档。通常,当程序员为工具编写注释以提取和生成文档时,他们的目标是介于两者之间的某个地方——刚刚足够的实现细节让用户感到厌烦和困惑,但不足以显著帮助维护者,并且没有足够的概述对用户有任何真正的帮助。

As a maintainer, I'd always rather have clean, clear comments, unmuddled by whatever strange markup your auto-doc tool requires, that tell me why you wrote that weird switch statement the way you did, or what bug this seemingly-redundant parameter check fixes, or whatever else I need to know to actually keep the code clean and bug-free as I work on it. I want this information right there in the code, adjacent to the code it's about, so I don't have to hunt down your website to find it in a state that lends itself to being read.

As a user, I'd always rather have a thorough, well-organized document (a set of web pages would be ideal, but I'd settle for a well-structured text file, too) telling me how your API is architectured, what methods do what, and how I can accomplish what I want to use your API to do. I don't want to see internally what classes you wrote to allow me to do work, or files they're in for that matter. And I certainly don't want to have to download your source so I can figure out exactly what's going on behind the curtain. If your documentation were good enough, I wouldn't have to.

无论如何,这就是我的看法。

世界需要更多的goto

人们虔诚地避免goto,除了“我的教授告诉我goto不好”之外,没有其他理由。它们有一个目的,可以在很多地方极大地简化生产代码。

也就是说,在你所编写的99%的代码中,它们都是不必要的。

c++是有史以来最糟糕的编程语言之一。

它具有委员会设计的所有特征——它不能很好地完成任何给定的工作,而且某些工作(如面向对象)做得很糟糕。它有一种“厨房水槽”的绝望,不会消失。

它是学习编程的可怕的“第一语言”。你(从语言中)得不到优雅,得不到帮助。取而代之的是陷阱和雷区(内存管理、模板等)。

它不是一种学习面向对象概念的好语言。它表现为“带有类包装器的C”,而不是一种合适的OO语言。

我可以继续讲下去,但现在就讲到这里。我从来不喜欢用c++编程,虽然我是在FORTRAN上“磨砺”的,但我完全喜欢用C编程。我仍然认为C是最伟大的“经典”语言之一。在我看来,c++肯定不是这样的。

欢呼,

-R

EDIT: To respond to the comments on teaching C++. You can teach C++ in two ways - either teaching it as C "on steroids" (start with variables, conditions, loops, etc), or teaching it as a pure "OO" language (start with classes, methods, etc). You can find teaching texts that use one or other of these approaches. I prefer the latter approach (OO first) as it does emphasize the capabilities of C++ as an OO language (which was the original design emphasis of C++). If you want to teach C++ "as C", then I think you should teach C, not C++.

但就我的经验而言,c++作为第一语言的问题在于,这门语言太大了,无法在一个学期内教授,而且大多数“介绍”文本试图涵盖所有内容。在“第一语言”课程中涵盖所有主题是不可能的。在我看来,你至少要把它分成两个学期,然后它就不再是“第一语言”了。

我确实教c++,但只是作为一种“新语言”——也就是说,你必须精通一些先前的“纯”语言(不是脚本或宏),然后才能注册这门课程。在我看来,c++是一种很好的“第二语言”。

-R

另一个编辑:(对康拉德)

I do not at all agree that C++ "is superior in every way" to C. I spent years coding C programs for microcontrollers and other embedded applications. The C compilers for these devices are highly optimized, often producing code as good as hand-coded assembler. When you move to C++, you gain a tremendous overhead imposed by the compiler in order to manage language features you may not use. In embedded applications, you gain little by adding classes and such, IMO. What you need is tight, clean code. You can write it in C++, but then you're really just writing C, and the C compilers are more optimized in these applications.

I wrote a MIDI engine, first in C, later in C++ (at the vendor's request) for an embedded controller (sound card). In the end, to meet the performance requirements (MIDI timings, etc) we had to revert to pure C for all of the core code. We were able to use C++ for the high-level code, and having classes was very sweet - but we needed C to get the performance at the lower level. The C code was an order of magnitude faster than the C++ code, but hand coded assembler was only slightly faster than the compiled C code. This was back in the early 1990s, just to place the events properly.

-R

单身人士并不邪恶

There is a place for singletons in the real world, and methods to get around them (i.e. monostate pattern) are simply singletons in disguise. For instance, a Logger is a perfect candidate for a singleton. Addtionally, so is a message pump. My current app uses distributed computing, and different objects need to be able to send appropriate messages. There should only be one message pump, and everyone should be able to access it. The alternative is passing an object to my message pump everywhere it might be needed and hoping that a new developer doesn't new one up without thinking and wonder why his messages are going nowhere. The uniqueness of the singleton is the most important part, not its availability. The singleton has its place in the world.