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

Don't avoid 1-element vectors/lists #345

Merged
merged 2 commits into from
Nov 4, 2021
Merged

Don't avoid 1-element vectors/lists #345

merged 2 commits into from
Nov 4, 2021

Conversation

vemv
Copy link
Member

@vemv vemv commented Oct 25, 2021

Fixes #344 / rationale there

Not necessarily for merging right away, before I'd like to know if you agree this is a better default?

Should we also provide an option to fall back?

Personally I wouldn't, there doesn't seem to be a huge rationale for the old behavior other than "make things shorter" which seems very relative when considering consistency with other tools or trends over the last few years.

@vemv vemv requested review from bbatsov and expez October 25, 2021 12:36
@bbatsov
Copy link
Member

bbatsov commented Oct 25, 2021

I'm fine with the proposal myself, but probably we should start some conversation in the style guide repo to see how others feel about this.

@vemv
Copy link
Member Author

vemv commented Oct 25, 2021

I'd feel ambivalent about that, not sure if refactor-nrepl should map 1:1 to clojure-style-guide, because it kind of would set the precedent that whatever the "community" might say over there would have to be implemented here.

I would be more cautious to follow the typical (but implicit) fashion of OSS: OSS projects implement what their maintainers deem adequate and willing to maintain.

No strong feelings attached to the whole issue, from my side. But I'd rather keep the conversation simple (pretty sure that the more people we ask, the more opinions we'll get 😄)

@vemv
Copy link
Member Author

vemv commented Oct 25, 2021

Worth pointing out, it it was critical, I'd add an optional flag as I did here clojure-emacs/clj-refactor.el#490 , but I'd bet that this topic is not as sensitve, so it's cheaper to defer the option until someone asks for it.

@expez
Copy link
Member

expez commented Oct 25, 2021

FWIW I find the extra parens noisy and don't like them :p

That said I can't remember the last time I actually looked at an ns form, beyond scanning for an alias, so I'm not going to oppose this if everyone else thinks this is better.

it's cheaper to defer the option until someone asks for it

👍

@bbatsov
Copy link
Member

bbatsov commented Oct 26, 2021

That's a fair point, although in general I've always tried to keep the project defaults with the community guidelines (as I happen to maintain both). Thinking a bit more about the proposed change I realized I like it for requires, but not so much for imports, as I feel they are kind of different. I almost never require something without an alias, but I very often import a single class from some package and the parens there seem like an overkill. Maybe those should be separate settings?

@vemv
Copy link
Member Author

vemv commented Oct 26, 2021

I'm willing to introduce that flag 👍

Personally I think that that choice introduces some complexities for consumers, e.g. sorting (does a-z go before (? Different formatters might disagree), git diffs/history (a ( is introduced/removed, now it has moved by 10 lines).

And good old M-x sort-lines will also fail to sort meaningfully IMO (there isn't much of a semantic difference between a-z imports and ( imports - yet a sort will be forced to group them by that criterion)

(:import
 (foo Bar Baz)
 (foo.baz Quux Quuz)
 java.net.URI)

The nice thing about autoformatters is that they do the hard work for you, so even 'overkill' options become cheap to produce.

@vemv vemv changed the title Don't avoid 1-element vectors/lists - POC Don't avoid 1-element vectors/lists Nov 4, 2021
@vemv vemv marked this pull request as ready for review November 4, 2021 06:34
@bbatsov bbatsov merged commit 044ff43 into master Nov 4, 2021
@bbatsov bbatsov deleted the 344 branch November 4, 2021 07:11
@camsaul
Copy link
Contributor

camsaul commented Dec 15, 2021

Is there a way to disable this?

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

Successfully merging this pull request may close these issues.

Don't avoid 1-element vectors/lists
4 participants