2024 Clojure 状态调查!中分享您的看法。

欢迎!请参阅关于页面,了解更多关于该功能的信息。

+6
Clojure
编辑

关于文档说明,针对键的解构是否是良好实践?我之所以问这个问题,是因为 Clj-kondo(Clojure 的一个代码检查器)报告了未使用的绑定。例如:

(let [x 1, y 2] y)

这会导致关于 x 未使用的警告。

有时人们这样做

(defn public-foo [{:keys [foo bar] :as x}]
  (private-baz x))

只是为了获得 public-foo 的更好文档字符串(或生成的文档)。但他们会收到关于 foobar 未使用的警告。以下是一个开源项目的示例:链接

解构在性能上并不是免费的,因此使用 spec 或 :arglists 可能是获得这些文档收益的更好选择。例如:

user=>
(defn public-foo
  {:arglists '([{:keys [foo bar] :as x}])}
  [x]
  ;; (private-baz x)
  )
#'user/public-foo
user=> (doc public-foo)
-------------------------
user/public-foo
([{:keys [foo bar], :as x}])
nil

在我为 clj-kondo 实现抑制函数参数中由键的解构引入的未使用绑定的警告功能之前,我希望对此达成共识。

6 答案

+3

我从不会为了文档说明而仅对 :keys 进行解构;您提到的替代方案听起来都更好。我经常添加 :as 部分(即使未使用它),但我确信在那种情况下不会有性能惩罚。

现在我有个自己的问题...为什么不用符号,比如 `{:keys [foo bar]}`?我猜这应该没什么区别,但有时很久以前应该学会的“小事情”就像一片玫瑰玛森时刻一样突然显现出来,所以我必须问问。

我们在该处使用关键词的一个原因是为了实现自动解析关键词支持(::),但这实际上已经被现在的:foo/keys和::keys所取代。所以,就使用符号吧。
我形成这种习惯是因为在一个流行的这种风格的代码库中工作,不是因为其他任何原因。
啊,我一直在使用`{:keys [:some/namespaced-keyword :some/other-keyword]}`,主要是因为这更容易找到用法:例如,查找`:some/namespaced-keyword`将找到完整的版本,但不会找到`{:some/keys [namespaced-keyword]}`。这样做有人反对吗?
没有,完全没问题。
0

在那个情况下,我的风格通常是

(defn public-foo [{:keys [foo bar] :as x}]
  (->> (private-baz foo bar)
    (assoc x :res)))
0

我从不为了文档中的arglists而进行解构。

在:keys中使用关键词而不是符号是一种很糟糕的做法。

0

我经常在fn声明中使用解构来为自己澄清用法。我理解这种做法会使linting变得更困难,但我认为这是人们会做到的事,有一个可以关闭linting通知的旋钮将会很不错。

现在这在clj-kondo中得到了支持:[配置文档](https://github.com/borkdude/clj-kondo/blob/master/doc/config.md#exclude-unused-bindings-from-being-reported)
0

我会认罪,但我不认为这是好的做法

0

我这样做,我喜欢它,但这只是一个观点,这里没有对错。

好的样式在很大程度上取决于观察者。警惕那些对这类琐事表示强烈意见的人。

...