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

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

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

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


当前回答

很快我们就会在一个没有 数据库。 AOP和依赖注入是的GOTO 21世纪。 开发软件是一种社交活动 活动,而不是技术活动。 乔尔有一个博客。

其他回答

大于运算符(>,>=)应该被弃用

我试着用“小于”而不是“大于”的偏好编码了一段时间,它卡住了!我不想回去,事实上,我觉得在这种情况下,每个人都应该按照我的方式去做。

考虑常见的数学“范围”符号:0 <= i < 10

这很容易在代码中近似,你已经习惯了在中间重复变量并用&&连接:

if (0 <= i && i < 10)
    return true;
else
    return false;

一旦你习惯了这种模式,你就再也不会觉得愚蠢了

if ( ! (i < 0 || i >= 9))
    return true;

同样的方法。

长序列的关系变得更容易处理,因为操作数倾向于非递减顺序。

此外,操作符<的优先级被铭记在c++标准中。在某些情况下,operator=是根据it来定义的!(a<b || b<a))

Requirements analysis, specification, design, and documentation will almost never fit into a "template." You are 100% of the time better off by starting with a blank document and beginning to type with a view of "I will explain this in such a way that if I were dead and someone else read this document, they would know everything that I know and see and understand now" and then organizing from there, letting section headings and such develop naturally and fit the task you are specifying, rather than being constrained to some business or school's idea of what your document should look like. If you have to do a diagram, rather than using somebody's formal and incomprehensible system, you're often better off just drawing a diagram that makes sense, with a clear legend, which actually specifies the system you are trying to specify and communicates the information that the developer on the other end (often you, after a few years) needs to receive.

[如果有必要,一旦您编写了真正的文档,您通常可以把它塞进组织强加给您的任何模板中。不过,你可能会发现自己不得不添加章节标题和重复的材料。

The only time templates for these kinds of documents make sense is when you have a large number of tasks which are very similar in nature, differing only in details. "Write a program to allow single-use remote login access through this modem bank, driving the terminal connection nexus with C-Kermit," "Produce a historical trend and forecast report for capacity usage," "Use this library to give all reports the ability to be faxed," "Fix this code for the year 2000 problem," and "Add database triggers to this table to populate a software product provided for us by a third-party vendor" can not all be described by the same template, no matter what people may think. And for the record, the requirements and design diagramming techniques that my college classes attempted to teach me and my classmates could not be used to specify a simple calculator program (and everyone knew it).

代码的重用与其“可重用性”成反比。因为“可重用的”代码更复杂,而快速的hack更容易理解,所以它们被重用。

软件故障应该使系统崩溃,以便对其进行检查和修复。试图处理失败条件的软件通常比崩溃更糟糕。也就是说,是在崩溃后重新设置系统更好,还是应该因为失败处理程序有一个错误而无限期地挂起系统?

如果你只能想到一种方法,那就别去做。

无论是一个界面布局,一个任务流,还是一段代码,都可以停止。做一些事情来收集更多的想法,比如询问其他人他们会怎么做,在你至少有三个完全不同的想法和至少一次信心危机之前,不要回去实施。

一般来说,当我认为某件事只能以一种方式完成,或者认为只有一种方法有任何优点时,那是因为我没有充分考虑应该彻底影响设计的因素。如果我这样做了,其中一些显然会发生冲突,导致混乱,从而做出实际的决定,而不是死记硬背的违约。

成为一个优秀的程序员并不意味着你就是一个优秀的界面设计师

遵循世界上所有的界面指南只会开始有所帮助。如果这是人类可能做到的…人们似乎有一种特殊的嗜好,就是把东西变得“可爱”和“聪明”。

这不是关于编程的,因为html/css不是编程语言。

表格可以用于布局

CSS和div不能做所有的事情,节省你自己的麻烦,使用一个简单的表,然后在它上面使用CSS。