你最具争议的编程观点是什么?

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

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

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

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

当前回答

三元操作符绝对糟糕。他们是懒惰编程的典型代表。

user->isLoggedIn() ? user->update() : user->askLogin();

这太容易搞砸了。修订2的一个小变化:

user->isLoggedIn() && user->isNotNew(time()) ? user->update() : user->askLogin();

哦，是的，只是一个“小改变”。

user->isLoggedIn() && user->isNotNew(time()) ? user->update() 
    : user->noCredentials() ? user->askSignup
        : user->askLogin();

哦，糟了，那另一个案子呢?

user->isLoggedIn() && user->isNotNew(time()) && !user->isBanned() ? user->update() 
    : user->noCredentials() || !user->isBanned() ? user->askSignup()
        : user->askLogin();

不不不不。只需要为我们保存代码更改。别再那么懒了:

if (user->isLoggedIn()) {
    user->update()
} else {
    user->askLogin();
}

因为如果第一次就做对了，我们就不必一次又一次地改变你的垃圾三元组:

if (user->isLoggedIn() && user->isNotNew(time()) && !user->isBanned()) {
    user->update()
} else {
    if (user->noCredentials() || !user->isBanned()) {
        user->askSignup();
    } else {
        user->askLogin();
    }
}

2009-11-04 02:18:57

其他回答

一幅画不如一千个词。

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

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

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

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

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

2009-01-03 10:53:43

手动停止程序是一种有效的、经过验证的查找性能问题的方法。

可信吗?对大多数人来说并非如此。真的吗?绝对的。

程序员的判断比必要的要多得多。

看看这些帖子中所有被认为是“邪恶”或“可怕”的事情吧。

程序员喜欢数据结构。

见证所有关于类、继承、私有与公共、内存管理等以及如何分析需求的讨论。

2009-01-02 14:21:34

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

2009-01-02 13:19:11

观点:SQL是代码。这样对待它