Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Threading macro alignment of first argument on it's own line #254

Open
dannyfreeman opened this issue Aug 6, 2023 · 2 comments
Open

Threading macro alignment of first argument on it's own line #254

dannyfreeman opened this issue Aug 6, 2023 · 2 comments

Comments

@dannyfreeman
Copy link

dannyfreeman commented Aug 6, 2023

Sometimes I find myself with a threading macro where I don't want the first argument to be on the same line as the threading symbols.

For example

(->>
 x
 foo
 bar

This guide does not recommend the number of spaces to indent the arguments with in this situation.
Clojure-mode default in Emacs indents 1 space from the opening (. cljfmt does the same.

I observe most people keeping the first argument on the same line as the threading macro symbol, and think it is the ideal way to align. However, sometimes lines get long and people drop the first argument down to. I'd like to add something like that into the guide for those situations.

Maybe change the threading macros alignment section could have a "not as good" part for this situation.

;; good
(->> (range)
     (filter even?)
     (take 5))

;; not as good
(->> 
 (range)
 (filter even?)
 (take 5))

;; bad
(->> (range)
  (filter even?)
  (take 5))

As for the alignment/offset to recommend, I don't have a preference. Since cljfmt uses 1 I'd recommend sticking with that since people use that tool for linting in CI/CD pipelines.

Happy to make the PR myself as well, but wanted to open an issue before doing that.

@seancorfield
Copy link
Collaborator

This made me check our codebase at work (~140k lines) and we have ~5,500 threading macro uses and just 16 of them have the first expression on a separate line.

Given that, I think I'd rather not encourage that layout and consider it one of those things where folks can break the "rules" if they really think it improves the readability -- so I don't think the guide needs to say anything about this case. It's already neither the "good" case nor the "bad" case so it is implicitly something in between.

@dannyfreeman
Copy link
Author

dannyfreeman commented Aug 7, 2023

Thanks for your reply Sean.

This made me check our codebase at work (~140k lines) and we have ~5,500 threading macro uses and just 16 of them have the first expression on a separate line.

I just checked a code base I have access to and found one instance of this, but that codebase was written with good linting and formatting checks in a ci/cd pipeline. Not surprised to only see a single instance there. Checked with ripgrep rg --multiline -e "->>?\n" **/*.clj

I originally asked this because my editor was indenting the arguments in these situations by 2 spaces and cljfmt was indenting it with 1. I am implementing tooling and had to make a decision about how to automatically indent in these situations. So I wanted to know, what is the best practice in this situation? I came to this guide for answers, but it had none for me. (I made a choice to match cljfmt in this case). I don't expect the style guide to have answers to everything but wanted to offer something up for this as I ran into it.

It's already neither the "good" case nor the "bad" case so it is implicitly something in between.

I agree, that is what I was trying to convey with the ;; not as good comment. There is precedence in the guide for things like this, which is where I got the terminology from. Some better terminology I think would be "if you must". I don't want to encourage it either, but some forms like this do exist in the wild. I wanted guidance for that and maybe others might as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants