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

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

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

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


当前回答

永远不要让最佳实践或模式困扰成为你的奴隶。

这些应该是指导方针,而不是一成不变的法律。

我真的很喜欢这些模式,GoF的书或多或少也是这么说的,这些东西可以浏览,提供了一个常见的术语。这不是无稽之谈。

其他回答

一幅画不如一千个词。

有些图片可能胜过千言万语。大多数都不是。这句陈词滥调大多是不真实的,是许多懒惰的经理的可悲借口,他们不想仔细阅读创建的报告和文档,说“我需要你在图表中展示给我看”。

我妻子学的是语言学专业,她看到了一些关于图片和标志的令人着迷的证据:它们不能打破语言和文化的障碍,它们通常不能像正确的文本那样传达那么多的信息,它们根本不能取代真正的交流。

特别是,如果线条未被标记且无法解释,并且/或如果每一行都有不同的含义而不是表示相同的关系(除非以某种方式彼此区分),那么与线条连接的标记气泡是无用的。如果你的线条有时表示关系,有时表示动作,有时表示时间的流逝,你就真的完蛋了。

每个优秀的程序员都知道你使用的工具适合手头的工作,对吗?并不是所有的系统都最好用图片来说明和记录。图形化规范语言可以自动转换为可证明正确的可执行代码或任何东西,这是一个了不起的想法,如果这样的东西存在的话。在适当的时候使用它们,而不是在阳光下的所有事情上。实体-关系图很棒。但并不是所有的事情都可以用一张图片来概括。

注:一张桌子可能值同等重量的金子。但是表格和图片不是一回事。同样,一篇精心设计的短散文段落可能更适合手头的工作。

(未命名)元组是邪恶的

如果您使用元组作为具有唯一含义的多个对象的容器,请改用类。 如果您使用它们来保存几个应该通过索引访问的对象,请使用列表。 如果您使用它们从一个方法中返回多个值,请使用Out参数(这需要您的语言支持引用传递) 如果这是代码混淆策略的一部分,那就继续使用它们!

我看到人们使用元组只是因为他们懒得给他们的对象命名。API的用户将被迫基于无意义的索引(而不是有用的名称)访问元组中的项。

代码即设计:Jack W. Reeves的三篇文章

任何软件的源代码都是其最准确的设计文档。其他的一切(规格,文档,有时还有注释)要么是不正确的,过时的,要么是误导性的。

肯定会让你在任何地方被炒。

我不明白为什么人们认为Java绝对是大学里最好的“首选”编程语言。

首先,我认为第一种编程语言应该强调学习控制流和变量的必要性,而不是对象和语法

另一方面,我相信没有在C / c++中调试内存泄漏经验的人无法完全理解Java带来的好处。

同样,自然的进展应该是从“我怎么能做这个”到“我怎么能找到做那个的库”,而不是相反。

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 :)