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

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

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

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


当前回答

意见:不应该有任何编译器警告,只有错误。你应该总是使用-Werror编译你的代码。

原因:要么编译器认为这是一个应该被纠正的错误,要么它不需要修复,在这种情况下编译器应该直接关闭。

其他回答

调试器是一种拐杖。

它的争议如此之大,以至于连我都不像以前那么相信它了。

缺点:我花了更多的时间来跟上其他人的大量代码,所以任何有助于“我是如何到达这里的”和“发生了什么”的事前或事后分析都是有帮助的。

教授:然而,我很高兴地支持这样的观点,如果你不理解你自己开发的代码或你已经熟悉的代码的这些问题的答案,把所有的时间都花在调试器上并不是解决方案,这是问题的一部分。

在点击“发布你的答案”之前,我快速地检查了一下这个确切的短语,结果发现我不是唯一一个持有这种观点或使用这个短语的人。我在Fog Creek软件论坛上找到了关于这个问题的长时间讨论,其中引用了包括Linus Torvalds在内的各种名人作为著名的支持者。

在开始构建电子系统之前,每个开发人员都应该花几周甚至几个月的时间来开发基于纸张的系统。他们还应该被迫使用他们的系统。

开发一个好的基于纸张的系统是一项艰苦的工作。它迫使你考虑人性(繁琐的过程会被忽略,过于复杂的过程往往会崩溃),并教会你欣赏简单的价值(新工作放在这个托盘里,QA工作放在这个托盘里,存档放在这个盒子里)。

一旦你弄清楚如何在纸上构建一个系统,构建一个有效的计算机系统通常会容易得多——一个人们实际上想要(并且能够)使用的系统。

我们开发的系统并不是由一群训练有素的自动机控制的;真实的人使用它们,真实的人由经理培训,经理也是真实的人,没有太多的时间浪费在培训他们如何跳过你的圈子。

事实上,关于我的第二点:

每个开发人员都应该被要求进行交互式培训课程,向用户展示如何使用他们的软件。

That (at least during initial design), every Database Table (well, almost every one) should be clearly defined to contain some clearly understanable business entity or system-level domain abstraction, and that whether or not you use it as a a primary key and as Foreign Keys in other dependant tables, some column (attribute) or subset of the table attributes should be clearly defined to represent a unique key for that table (entity/abstraction). This is the only way to ensure that the overall table structure represents a logically consistent representation of the complete system data structure, without overlap or misunbderstood flattening. I am a firm believeer in using non-meaningful surrogate keys for Pks and Fks and join functionality, (for performance, ease of use, and other reasons), but I beleive the tendency in this direction has taken the database community too far away from the original Cobb principles, and we jhave lost much of the benefits (of database consistency) that natural keys provided.

那么为什么不两者都用呢?

如果我有争议的话,我不得不说乔恩·斯基特并不是万能的。

世界需要更多的goto

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

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