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

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

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

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


当前回答

使用较短的变量名是可以的

但不是嵌套循环中的索引。

其他回答

Visual Basic和c#都不能胜过对方。除了一些语法和格式之外,它们几乎是一样的。

扩展方法是魔鬼的工作

Everyone seems to think that extension methods in .Net are the best thing since sliced bread. The number of developers singing their praises seems to rise by the minute but I'm afraid I can't help but despise them and unless someone can come up with a brilliant justification or example that I haven't already heard then I will never write one. I recently came across this thread and I must say reading the examples of the highest voted extensions made me feel a little like vomiting (metaphorically of course).

主要原因是增加了可读性、改进了oo性以及更好地连接方法调用的能力。

I'm afraid I have to differ, I find in fact that they, unequivocally, reduce readability and OO-ness by virtue of the fact that they are at their core a lie. If you need a utility method that acts upon an object then write a utility method that acts on that object don't lie to me. When I see aString.SortMeBackwardsUsingKlingonSortOrder then string should have that method because that is telling me something about the string object not something about the AnnoyingNerdReferences.StringUtilities class.

LINQ是这样设计的,链式方法调用是必要的,以避免奇怪和不舒服的表达式,来自LINQ的扩展方法是可以理解的,但一般来说,链式方法调用降低了可读性,并导致我们在混乱的Perl竞赛中看到的那种代码。

因此,简而言之,扩展方法是邪恶的。摆脱撒旦的枷锁,致力于自由扩展代码。

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.

远离Celko!!!!

http://www.dbdebunk.com/page/page/857309.htm

我认为使用代理主键比使用“自然”主键更有意义。


@ocdecio: Fabian Pascal给出了(在他的书《数据库管理中的实际问题》的第三章中,引用于你链接的页面的第3点)作为选择键的标准之一,那就是稳定性(它总是存在并且不会改变)。当一个自然键不具有这样的属性时,必须使用一个代理键,原因很明显,您在注释中暗示了这一点。

你不知道他写了什么,你也懒得去检查,否则你会发现你实际上同意他的观点。这里没有什么争议:他说的是“不要教条主义,根据情况调整一般的指导方针,最重要的是,思考,用你的大脑,而不是教条主义/食谱/大师的话”。