命名空间默认别名

Question

在较大的代码库和团队中，不同的人可能会使用不同的别名来 'require' 命名空间。

h.clj
(ns hello.core)

f.clj
(ns foo.core
    (:require [hello.core :as hc]))

b.clj
(ns bar.core
    (:require [hello.core :as h]))

如果您看到，我参与的大型项目通常会存在相同的命名空间具有不同别名的现象，即使保持了约定。这是一种人类错误，在较大的团队中，这通常会导致偏离轨道。这使得使用grep等简单工具查找命名空间和其中的函数用法变得更加困难（如上面的示例中执行 hc/some-func 或 h/some-func）。

我想提出的是，在 ns 宏本身中可以有一些类似的内容

(ns hello.core :default-alias <my-alias>)

在需要此 ns 的任何地方

(ns foo.core 
    (:require [hello.core :default-alias])

我们将自动获得对命名空间的 <my-alias> 引用，因此我们可以执行 <my-alias>/some-func

这将导致在语言级别强制执行的统一代码
我相信这可以通过将某些元数据存储在命名空间中来实现

Answer 1

您可以在clj-kondo中使用:consistent-alias代码检查器来强制这种一致性

https://github.com/borkdude/clj-kondo/blob/master/doc/config.md#alias-consistency

Comments

太棒了！作为后续问题，clj-kondo是否有用户配置？例如，我想有跨项目默认（配置）或者制定团队规范？

---

用户配置不是本设计的支持内容。您可以在这里阅读设计原则第5条：[链接](https://github.com/borkdude/clj-kondo/blob/master/doc/dev.md)
如果这对您很重要，我建议您简单地写一个小的模板脚本、lein模板或clj新模板，只复制配置。

Answer 2

你好，感谢你的建议，这是我之前没有看到过的。

我认为这个提案的一个缺点是别名会“从天而降”，这本身就带来了一定的问题。我的意思是，当然这也是其目的之一，但仅仅从特定的消费者命名空间来看，如果不找到和解析所有其他引用的命名空间，是无法知道别名指的是什么的。

无论如何，我们不想给ns宏或命名空间系统增加额外的复杂性，所以我认为不大可能添加这样的功能。

Comments

是啊，我也担心“从天而降”的问题：）

不管怎样，我会自己在Clojure分支上尝试一下

---

这个提案的其他问题

如果源命名空间因任何原因更改了默认别名，所有的消耗性代码都会断开。

如果两个命名空间恰好有相同的默认别名，并且你尝试引入它们，就会发生冲突。

任何依赖静态检查代码的工具都不会知道(hc/greet)是什么——目前它们看到：as hc别名，可以“解析”hc/greet符号，而无需加载命名空间。