Omit parentheses in threading macros when optional
MicahElliott opened this issue · 5 comments
Parentheses are not required when using the threading macros for functions having no argument specified, so use them only when necessary.
;; good
(-> x fizz :foo first frob)
;; bad; parens add clutter and are not needed
(-> x (fizz) (:foo) (first) (frob))
;; good, parens are necessary with an arg
(-> x
(fizz a b)
:foo
first
(frob x y))Yeah, that's a good guideline to have. PR welcome! :-)
The wording of this is incorrect and misleading on how the threading macro works.
A function that takes zero arguments would break the threading of the threading macro unless its the very first in the sequence.
Each following function must take at least one argument otherwise an arity exception would be called as proceeding lines are passing an argument into the next line - it is the result of each expression that is threaded through the threading macro. I assume this is why it has this name.
The idiom more specifically is: parens must be used when functions have more than one argument, otherwise the parens are optional.
I would disagree that its bad style to include parens, they are simply optional. The language used for this style could be more constructive too. Perhaps finding a way to widen the review of style guide lines is something to consider.
What's wrong with the wording exactly?
"functions having no argument specified" is not the same as a function with 0 arguments, so to me it seems that the wording is correct, although probably there's some room for improvement.
I would disagree that its bad style to include parens, they are simply optional.
Well, it's not necessary bad, it's just not very common either. We can make this more explicit in the description.
Perhaps finding a way to widen the review of style guide lines is something to consider.
I keep issues open for a very long time to solicit some conversations, but usually people join the conversations only when something gets merged. 😆 We can certainly do better, but I also don't want to run around looking for input.
In general it seems to me that the guideline is not bad, but it can be worded better.
"functions having no argument specified" is not the same as a function with 0 arguments, so to me it seems that the wording is correct, although probably there's some room for improvement.
I find the term "specified" quite vague. Specify sounds more like a function definition than a function call, hence why I found the description could lead to the assumption that the rule was for functions that did not take any arguments.
Argument are passed to a function, or a function is called with arguments, or a function that takes x number of arguments.
I would disagree that its bad style to include parens, they are simply optional.
Well, it's not necessary bad, it's just not very common either. We can make this more explicit in the description.
Perhaps finding a way to widen the review of style guide lines is something to consider.
I keep issues open for a very long time to solicit some conversations, but usually people join the conversations only when something gets merged. laughing We can certainly do better, but I also don't want to run around looking for input.
The community doesnt tend to actively watch a GitHub repository unless they are raising an issue or pull requests. Adding a channel to the Clojurians slack / zulip for discussions could help widen the discussion.
The same issue of late comments has occurred when contributing key bindings to Spacemacs, so I posted links to issues and PRs as I raised them to elicit discussion. There are also other channels where the community lives that could help.
The community doesnt tend to actively watch a GitHub repository unless they are raising an issue or pull requests. Adding a channel to the Clojurians slack / zulip for discussions could help widen the discussion.
Yeah, I totally get this. Adding some channel about conversations on Slack seems like a good idea.