我们应该寻找说谎的代码吗？

这是指答案中的讨论和对该问题的评论：业界对文档的厌恶是什么？。答案声称“代码不能撒谎”，因此应该是定位位置，而不是文档位置。一些评论指出“代码可能存在”。双方都有真相，至少部分是由于文档处理的差劲和不适当。

我们是否应该寻找说谎的代码，并将其与任何现有文档进行比较？还是通常它是所需要做的事情的最佳来源？如果它是敏捷代码，那么它说谎的可能性较小，还是该代码根本不说谎？

用外行的话来说：

是的，您应该搜索撒谎的代码并说出真相。但是不能将其与文档进行比较。那将是一种检测谎言的方法。

有几种方法可以掩盖代码，我将仅提及其中几种：

• 由于永远不会满足条件而永远不会运行的代码块。该代码使您了解它的功能。
• 增加不必要的复杂性的代码在于问题的真正复杂性。
• 没有命名约定的代码之所以存在，是因为它使您误认为它所做的事情与实际所做的不同。

越短，它越少。这是不言而喻的。

代码越简单，则代码越透明。因此，它的谎言更少。

奥术语法技巧很多。最好使用清晰的分步算法。他们撒谎。

一个好的静态代码分析工具可以帮助您找到隐藏的代码。

好的自动测试电池也可以迫使代码讲真话。

代码不能撒谎。

代码中的内容是您的程序当前正在执行的操作-无论使用什么文档，质量检查或客户说什么。特别是如果您的代码已经发布并且已经存在了一段时间，则不应忽略该预期行为。

该代码肯定是不正确的。它的命名或组织肯定会产生误导。它肯定是不可读的。

但是，如果您想了解代码在做什么的真理源，而不是代码应该做的事情，不是代码旨在做的事情，而不是您认为代码正在做的事情……如果您需要知道代码实际上在做什么，转到代码。

你问几个问题。

我们应该注意说谎的代码吗？

当然！

我们应该将[代码]与任何现有文档进行比较吗？

尽管永远不会有任何伤害，尽管正如其他答案中提到的那样，这通常会导致您在文档中而不是代码中发现问题。

还是[code]通常是执行所需工作的最佳来源？

它始终是所做工作的最佳来源。但是，代码应该做的最佳来源可以是（不同的）组合（主要是）：

• 代码本身；
• 调用代码；
• 该代码中的注释；
• 文件；
• 单元测试；
• 整合和回归测试；
• 程序员；
• 最终用户；

哪个“最佳”来源（或其组合）取决于您的情况。

如果它是敏捷代码，那么它说谎的可能性较小，还是该代码根本不说谎？

我不确定“敏捷代码”是什么意思，AFAIK“敏捷”通常是指编码过程。假设您的意思是“在敏捷编程过程中创建的代码”，那么我可以肯定地说它仍然可以说谎。与在瀑布式项目中创建的代码相比，说谎的可能性是一个主观的问题（就我个人而言，我认为没有太大的联系）。

脚注
以上所有内容均基于可以存在代码的假设，并且这是一个基本的（尽管有些人为的）示例：

public int DivideByTwo(int input) 
{
    return input / 3;
}

这只是我会说“代码说谎”的一个示例，@ user61852还有其他一些示例（无法访问的代码，代码的复杂性与问题的复杂性不匹配，命名错误），而且我想还有更多示例。维基百科的谎言摘要相当不错，其中许多可以找到代码。

请注意，如果您与某人发生争执，请务必确保另一人的意思不是“代码不能说谎”，即“代码可以做到”。本质上，这里的另一个人使用“谎言”的定义进行定义，该定义是如此狭窄，以至于可以将“代码不能说谎”声明声明为公理/基本真理。在这种情况下，最好是同意他/她的公理。

if (x > 5) {
  doSomething();
} else {
  doADifferentThing();
}

您可以争论“谎言”一词在技术上是否适当，但此代码清楚地暗示着x 有时会大于5，有时不大于5。如果您查看整个程序，发现该函数只在一个位置调用过，并且x始终设置为常数6，那是个谎言。

而且，编译器可能已经注意到了这一点，并用简单的代码替换了这段代码

doSomething()

如果在程序的其他位置未调用doADifferentThing，则可能会将其完全从程序中删除。

如果您的语言支持assert某种在生产环境中已关闭的语言，则每个assert语句都可能是谎言。类型转换是另一个可能是谎言的断言。