在我职业生涯早期读到的一条建议是“布尔值几乎永远不应该作为函数的参数”。我当时并不明白问题所在，但后来在一家拥有大量Lua代码库（主要由一到两个开发者编写）的公司工作时，发现了许多看起来像这样的代码行：serialize(someObject, true, false, nil, true) 那些额外的参数有什么作用？谁知道呢，不查看函数定义是不可能知道的。基本上，发生的情况是，开发者编写了一个函数（“serialize”，在这个例子中），然后后来发现某些情况下需要稍微不同的行为（可能是格式化输出之类的）。由于Lua允许在不更改调用点的情况下更改函数的参数数量（缺少的参数只是nil），他们就只是添加了一个标志作为参数。然后又添加了另一个标志。再然后又添加了另一个。我现在非常坚定地认为，你几乎永远不应该将布尔值作为函数的参数。当然有例外，但非常少。
源讨论那个布尔值可能应该换成其他东西原帖 136 条评论 · 导入时统计把你的经验，加入这段讨论。
如果你使用关键字参数，那么类似这样的情况看起来不会太糟糕： serialize(someObject, prettyPrint:true) 注意：我不确定Lua是否支持关键字参数，但如果你的编程语言支持的话，这似乎可以解决你遇到的具体问题？
完整原文这是许多旧语言类型系统的一个缺陷（除了Pascal）。 在许多语言中，标志的最佳方法是使用位运算或的无符号整数。 在伪代码中： Object someObject; foo (someObject, Object.Flag1 | Object.Flag2 | Object.Flag3); 无论你使用的是哪种语言，它可能都有某种命名空间的方式来定义标志为`(1 << 0)`和`(1 << 1)`等。
完整原文但这其实并不是布尔值的问题——即使在你的例子中，还有一个神秘的参数：nil 你也可以在任何参数类型中遇到同样的问题。copy(obectA, objectB, "")中的参数是什么意思呢？ 一般来说，你需要某种方式来传达参数的用途——命名参数、IDE自动补全，不管是什么方式——一旦你有了这个，布尔值和其他类型一样好。
完整原文> 我现在非常坚定地认为，你几乎永远不应该将布尔值作为函数的参数。有例外情况，但不多。 真的吗？这听起来在某些特定上下文之外是不合理的。作为一条普遍规则，我无法理解。 我不明白这有什么根本性的问题。替代方案是什么？多个静态函数，有不同的名称对应不同的标志，加上代码重复，以及使用switch语句来选择正确的函数？ 或者你有其他观点？
完整原文命名参数正是解决这个问题的方法。有了可选参数和默认值，你就可以像你在Lua代码中所做的那样，但代码会更加自解释。 我个人坚信，人们不应该使用缺乏基本功能的编程语言。
完整原文我在Elixir中非常喜欢的一点是，函数可以有相同的名字，但根据参数个数不同而被视为不同的函数。 https://elixirschool.com/en/lessons/basics/functions#functio...
完整原文每当我写下： JSON.stringify(val, null, 2); 时，我都会感到很痛苦。（是的，但这种情况不仅仅限于布尔值。所有可选参数都应该使用命名参数。）
完整原文我惊讶竟然没人建議過這個。只要為這個函數使用不同的名稱就可以了。在你的範例中，新的函數應該是prettyPrint()。不需要布林值。也不需要額外的結構。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。