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

Formatting let bindings #8

Open
Tracked by #14
danielcompton opened this issue Dec 9, 2018 · 5 comments
Open
Tracked by #14

Formatting let bindings #8

danielcompton opened this issue Dec 9, 2018 · 5 comments

Comments

@danielcompton
Copy link
Member

Similar to #7 on formatting maps, how should let bindings be formatted? Should all of the init-forms (right hand side) be aligned, or have a ragged alignment?

(let [a nil
      very-long-symbol {}])

;; or

(let [a                nil
      very-long-symbol {}])

Should lines that are destructuring collections be handled differently? They can get very long and would cause large gaps in let bindings if they were included.

@PEZ
Copy link

PEZ commented Dec 9, 2018

I vote for aligning ”simple” let bindings and handle the destructuring ones differently. What that ”differently” means is another matter. What are some common patterns in use out there?

@PEZ
Copy link

PEZ commented Dec 9, 2018

As with #7 there is the issue of enforcing alignment might make adding bindings cause some diff tools to report more differences than really are there.

@danielcompton
Copy link
Member Author

I vote for aligning ”simple” let bindings and handle the destructuring ones differently. What that ”differently” means is another matter. What are some common patterns in use out there?

Cursive just puts one space between the binding and the init-form:

(let [subject-date (js/goog.date.DateTime.)
      a            nil
      {:keys [x y z ab]} {}]
...

@PEZ
Copy link

PEZ commented Dec 10, 2018

What I started to think about was rather how people format the destructurings, but maybe that is just following any rules for maps and vectors?

@danielcompton
Copy link
Member Author

Ah right, yes that's also another thing to consider, and would probably end up being treated the same.

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