Lisp/Clojure 代码在语法上具有一致性，这是一个加分点，因为人们不需要理解各种不同的结构。
但有时通过查看一段代码更容易理解，只是通过使用不同的语法，比如这是一个 switch case 或者这是模式匹配构造等，而无需实际阅读文本。
几个月前我开始使用 Clojure，我意识到如果不阅读表单的名称，然后在谷歌上搜索它是宏还是函数以及它是如何工作的，我就无法理解代码。
所以事实证明，一段 Clojure 代码，不管语法是否统一，都不是统一的。
它可能看起来像一个函数，但如果它是一个宏，那么它可能不会评估它的所有参数。
是否有所有宏都使用的命名约定或缩进样式，以便某人通过名称更容易掌握发生了什么？
最佳答案
在我看来，最有用的直觉来自于理解给定运算符/Var 的目的。设计良好的宏根本无法编写为函数，并且仍然提供具有相同语法的相同功能，因为如果可以，它们实际上会编写为函数(请参阅上面的“精心设计”部分!)。1 所以，如果您正在处理一个不可能是常规函数的构造，那么您知道它不是；否则很可能是。
此外，了解库导出的变量的常用方法会告诉您您是在处理宏还是预先处理函数。 doc 也是如此( (doc foo) 表示 foo 是靠近其输出顶部的宏，如果确实如此)，source (因为它为您提供了完整的代码)和 M-。 (使用 nrepl.el 或 swank-clojure 跳转到 Emacs 中的定义；M-，跳回)。文档可能会提到什么是宏，什么不是(除了文档字符串不一定是这样，因为访问文档字符串的所有常用方法都已经告诉您是否正在处理宏，如上所述)。
如果您浏览一段代码的目的是粗略地理解它可能在假设各种运算符执行其名称所建议的功能的情况下所做的事情，那么要么(1)名称具有足够的暗示性，您就会得到了解代码的意图，因此您甚至不需要关心哪些运算符恰好是宏，或者 (2) 名称不够暗示，因此您需要深入了解文档或源代码无论如何，一些运算符，然后您将学习的第一件事是它们中的哪些被注册为宏。
最后，宏没有单一的命名风格，尽管有特定于特定用例的某些约定。例如 with-foo -style 结构往往是方便的宏，其目的是简化对 foo 类型资源的处理。 ; dofoo -style 结构往往是宏，它采用要执行的表达式主体(设置多少次以及设置的附加上下文取决于宏；该家族的最基本成员 do 实际上是一种特殊形式，而不是比宏)； deffoo -style 构造引入了新的 Vars 或类似类型的实体。
值得指出的是，类似的模式有时会被打破。例如，大多数线程构造(-> & Co.)是宏，但 xml->来自 clojure.data.zip.xml是一个函数。当我们考虑所提供的功能时，这是完全有道理的，这让我们回到了关于运算符是最有用的直觉来源的目的这一点。
1 此规则可能有一些异常(exception)。人们希望这些都被记录在案。有些项目当然根本没有记录(或几乎没有记录)；在这里，问题完全消失了，因为无论如何都必须去源头弄明白事情的意思。
关于clojure - 如何在查看 Clojure 代码时识别哪些表单是宏，哪些是函数？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17826308/