Open thewatts opened 7 months ago
Hey Nathaniel, thanks for the kind note. I appreciate your perspective and see where you're coming from.
Personally, seeing foo:,
doesn't look any more or less jarring than a naked foo:
(in truth, they're both unsettling to my eyes). I've been using this shortcut in earnest for a few months, though, and I generally prefer anything that lets me be terser.
Ultimately, I'm still :-1: on this, for these reasons:
Thanks again for submitting this. Will leave it open for others who want to comment
Yes. And everywhere else. Please!
Quoting @zacheryph from rubocop/ruby-style-guide#273:
Not having this one single comma now adds unnecessary overhead every time you touch this code. While these may be minor, and take all of 5 seconds to fix; It is still overhead. Something a style guide should be trying to reduce?
- every time you look at a diff you might be looking at noise
- every time you append an entry you need to alter a line unrelated to your change
- every time you remove an entry you might need to alter a line unrelated to your change
- every time you shuffle/reorder that array/hash you might need to shuffle a comma around
Why is the last entry of an array/hash this special? Shouldn't we be trying to reduce exceptions in our coding styles?
- all entries get a comma... EXCEPT the last one, you are special.
- Add code. EXCEPT to the end of an array/hash. You might need to touch lines you aren't concerned about
I'm really frustrated about this after months of adopting Standard Ruby.
Yes. And everywhere else. Please!
Quoting @zacheryph from rubocop/ruby-style-guide#273:
Not having this one single comma now adds unnecessary overhead every time you touch this code. While these may be minor, and take all of 5 seconds to fix; It is still overhead. Something a style guide should be trying to reduce?
- every time you look at a diff you might be looking at noise
- every time you append an entry you need to alter a line unrelated to your change
- every time you remove an entry you might need to alter a line unrelated to your change
- every time you shuffle/reorder that array/hash you might need to shuffle a comma around
Why is the last entry of an array/hash this special? Shouldn't we be trying to reduce exceptions in our coding styles?
- all entries get a comma... EXCEPT the last one, you are special.
- Add code. EXCEPT to the end of an array/hash. You might need to touch lines you aren't concerned about
I'm really frustrated about this after months of adopting Standard Ruby.
Someone will always be frustrated by some stylistic decision. That's pretty much unavoidable.
Generally Standard strives not to make people type more than necessary
I would argue that with this rule standard makes me type more: if I want to add a line I duplicate an interesting line (yyp
or similar some shortcut) that will make me type less. Then the editor yells at me until I either fix the comma manually or write the file (which I may not want to do right away).
Similarly for macros or multicursor edits the last item missing a comma prevents automatically repeated operations (e.g ct,
or something) to be applied easily and consistently.
In short, regularity makes one type less. The last item being irregular is painful, not just for "personal taste" reasons but for technical automation reasons.
First off, I love this project, and it's brought significant joy to my life and the lives of my team.
Truly - thank you for the significant amount of hard work, and hard decisions, you all have had to make.
I'm aware that this issue (for other reasons) has been talked about before.
My goal with this issue isn't to bike-shed, or cause stress. I just wanted to make a suggestion here, given some (somewhat) recent changes with what's possible in Ruby, and how I feel the current trailing commas rule causes some visual friction when writing/reviewing code.
This is just my opinion here, and I'm in no way saying everyone should have it - but I feel like others may find it valid.
My premise: enforcing "avoiding comma after last item of a hash" (as opposed to the opposite), hurts code readability with implicit hash values.
Here's a example below:
Say we have some class that builds up a hash value, and it just so happens that:
To my eyes, when scanning this code, it looks like
favorite_color
is missing its value (particularly if I don't know - due to the size of the file, etc, that thefavorite_color
method exists). I can't help but think that there's a problem with the file/code when reading it.Whereas the opposite:
My eyes see the
,
and my brain automatically assumes that we're implicitly referencing a method/variable somewhere - and can continue reviewing the file without my brain hitting the breaks.Additionally, here's an example diff from a PR in a project:
I'm unsure if this resonates with everyone, and if you all disagree — I completely understand. I just thought I'd mention it, as it has come up for me multiple times as a code writer and reviewer.