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

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

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

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


当前回答

默认情况下,所有变量/属性都应该是只读/final。

这个推理有点类似于Jon提出的类的封闭论证。程序中的一个实体应该有一个任务,而且只有一个任务。特别是,对于大多数变量和属性来说,改变值是绝对没有意义的。基本上有两个例外。

Loop variables. But then, I argue that the variable actually doesn't change value at all. Rather, it goes out of scope at the end of the loop and is re-instantiated in the next turn. Therefore, immutability would work nicely with loop variables and everyone who tries to change a loop variable's value by hand should go straight to hell. Accumulators. For example, imagine the case of summing over the values in an array, or even a list/string that accumulates some information about something else. Today, there are better means to accomplish the same goal. Functional languages have higher-order functions, Python has list comprehension and .NET has LINQ. In all these cases, there is no need for a mutable accumulator / result holder. Consider the special case of string concatenation. In many environments (.NET, Java), strings are actually immutables. Why then allow an assignment to a string variable at all? Much better to use a builder class (i.e. a StringBuilder) all along.

我意识到,今天的大多数语言并没有默认我的愿望。在我看来,由于这个原因,所有这些语言都有根本性的缺陷。如果将它们更改为默认将所有变量视为只读,并且在初始化后不允许对它们进行任何赋值,那么它们的表达性、功能和易用性将不会受到任何损失。

其他回答

不断测试

您必须编写测试,并且必须首先编写它们。编写测试会改变编写代码的方式。它会让你思考你想要它实际做什么,然后再开始写一些东西,它能做所有事情,除了你想要它做的。

它也给你目标。看着你的测试变绿会让你有额外的信心,因为你完成了一些事情。

它还为您为边缘情况编写测试提供了基础。由于您一开始就针对测试编写代码,因此您的代码中可能有一些用于测试的钩子。

没有理由不测试你的代码。如果你不这样做,那你只是懒惰。我还认为您应该先进行测试,因为这样做的好处超过了编写代码所花费的额外时间。

估计是给我的,不是给你的

作为开发部门经理,评估对我来说是一个有用的工具,可以用来计划我的团队正在做什么。

它们不是在特定日期交付特性的承诺,也不是驱使团队更加努力工作的棍子。

恕我直言,如果你强迫开发者做出估算,你就能得到最安全的数字。

例如:

我认为一个专题大概需要5天左右的时间。有很小的可能性出现问题,需要30天。 如果评估只是为了计划,那么我们都将工作到5天,并考虑到出现问题的小概率。 然而,如果满足这个估计是交付承诺的要求,你认为会给出什么样的估计?

如果开发人员的奖金或工作保障取决于是否达到估算值,你认为他们给出的是最准确的猜测还是他们最确定会达到的估计?

我的这一观点与其他管理层存在争议,并被解释为我试图钻出合适的目标,或者我试图掩盖糟糕的表现。每次都很难说服别人,但我已经习惯了。

大多数专业程序员都很糟糕

我遇到过太多为了谋生而做这份工作的人,他们对自己所做的事情很糟糕。蹩脚的代码,糟糕的沟通技巧,对新技术毫无兴趣。太多太多了……

Xah Lee: actually has some pretty noteworthy and legitimate viewpoints if you can filter out all the invective, and rationally evaluate statements without agreeing (or disagreeing) based solely on the personality behind the statements. A lot of my "controversial" viewpoints have been echoed by him, and other notorious "trolls" who have criticized languages or tools I use(d) on a regular basis. [Documentation Generators](http://en.wikipedia.or /wiki/Comparison_of_documentation_generators): ... the kind where the creator invented some custom-made especially-for-documenting-sourcecode roll-your-own syntax (including, but not limited to JavaDoc) are totally superfluous and a waste of time because: 1) They are underused by the people who should be using them the most; and 2) All of these mini-documentation-languages all of them could easily be replaced with YAML

我讨厌大学和研究所向新人提供短期编程课程。这完全是对编程艺术和科学的耻辱和蔑视。

他们开始教C, Java, VB(恶心)给那些没有很好地掌握硬件和计算机基本原理的人。 首先应该通过Morris Mano的《计算机系统体系结构》等书籍来教授机器,然后教授指令机器解决问题的概念,而不是蚀写一种编程语言的语义和语法。

我也不理解政府学校和大学教孩子使用商业操作系统和软件的计算机基础知识。至少在我的国家(印度),没有多少学生买得起操作系统,甚至打折的办公套装,更不用说开发软件的巨头(编译器,ide等)。这就引发了盗窃和盗版,并使这种从他们机构的图书馆复制和窃取软件的行为成为一种正当的行为。

他们再次被教导使用一些产品,而不是基本的理念。

试想一下,如果你只被教导2x2 = 4,而没有被教导乘法的概念?

或者,如果你现在被教去测量倾斜在学校复合墙上的杆子的长度,而不是毕达哥拉斯定理