> Obnoxious: come up with a set of style preferences, write some post-hoc justification, and then name it in a way that implies anyone who has different preferences is doing something wrong
Like 'responsible disclosure'... implies only someone who is 'irresponsible' could disagree with it. Presumably everyone thinks their disclosure process is responsible, otherwise they wouldn't do it.
> Doublespeak is language that deliberately obscures, disguises, distorts, or reverses the meaning of words. Doublespeak may take the form of euphemisms (e.g., "downsizing" for layoffs and "servicing the target" for bombing),[1] in which case it is primarily meant to make the truth sound more palatable. […]
It’s funny, this is the kind of thing that’s meant to end bike shedding, but to me this is the ultimate bike shed.
I like linters, and having a good default config out of the box is a good idea. But the idea that you need an entire language community to agree to only ever do anything one specific way is just kind of silly IMO.
What projects like these say to me is that there are too many teams with poor leadership who spend far too much time bickering over things like which linter rules to use, and thus feel that invoking a higher power (the “standard,” in this case), is the only thing that will save them.
Now that this problem is “solved,” what new crisis caused by a lack of leadership will present itself?
It's the ultimate bike shed and it's trying to push the idea that it's only taking away choice that doesn't matter. But generally with tools like this, if you try arguing for different settings, you'll find very quickly that the reasons these tools have the rules they do is that the people writing these tools tend to have very strong ideas about what the rules should be and how important it is they're all the same.
That's how I generally feel about it. Strategies like these are usually covering up the symptoms while leaving the root problems in place. "We aren't arguing so it's clearly going well".
Thing is, I _want_ my team members to argue over coding styles and patterns. I _want_ people to present different techniques and approaches, and for everyone to weigh in with what they like and they don't like. I _want_ people to be pushed to consider new things and and perspectives, and to challenge their accepted notions on how to code.
The true root cause, I think, is that many people know how to argue, but very few people now how to argue constructively. Where the goal isn't for one person to win, but for everyone to discuss ideas while tracing back our shared interests until the proper solution presents itself. I wish more people took the time to develop such a skill.
Patterns are good but the minutiae that most linters deal with aren’t that. A discussion over formatting rules is more often than not a distraction and a waste of time — if it’s not there, better discussion can come out of code review.
That differs from my opinion on the matter. If two programmers disagree over formatting, I want to learn the needs of each programmer and how those needs inform their formatting preference. Understanding each others needs, and being respectful of each others needs, is a primary component of good teamwork. Those needs aren't exposed when a linter prevents the variance from ever becoming clear.
Notice how in these threads, the people who think that the specific formatting doesn't matter tends to be the ones supporting tools that tries to force a specific formatting.
To me the formatting does matter. It is a major factor in how comprehensible a code-base is, and often having freedom to deviate from the expected rules to line things up in certain ways helps to convey patterns and similarity that matters.
I learned a lot about how to debate more constructively second-hand from my business partner who took the class referenced here [1]. The “crossing the net” tool was especially helpful to me once I started actively noticing how often I did it. Really trying to follow that forced me to ask better questions to understand where my views differed and why. All 5 tips are good areas to reflect on and experiment with, though.
To me it seems less like they think this ought to be forced upon or adopted by the entire Ruby community or whatever.
The big benefit to me would be as a maintainer of an open source project. I can use this, & I never have to consider whether or not someone’s suggestion to change a linter rule is worth listening to or not.
You achieve exactly the same by insisting your project, your linter rules. There's no difference, because someone can just as well argue you should replace your use of this project with something else.
I also have a substantial piece of Rubocop config that I use for my own projects. Why is anyone else's better than mine, or vice versa?
Why do have people have to name their preferences 'standard' and promote them around?
Such initiatives simply add heat, noise and confusion to a perfectly fine and diverse community that can sport a palpable history of giving extreme power to its hackers.
So it's just Rubocop, but non-configurable (standard rules only). I don't mind any of the rules they've picked, other than the "no single quote strings", but I suppose that's the point - I don't get to have an opinion :-D
I'm not excited. I think it's very important to have good defaults. But "you can't configure it" means you can't have changes that adjust to the situation.
Let's look at a mentioned example:
> Increase consistency around things that don’t matter. For example, Standard requires all string literals be double-quoted. Single-quotes don’t support interpolation but aren’t any more performant, so mixing single & double quoted strings adds a bit of cognitive overhead with zero discernible benefit.
But there are discernable benefits. Single-quotes are great for indicating "there is no interpolation here" and for strings that embed double-quotes.
Rubocop is great, though, and highly recommended if you do Ruby things.
> Single-quotes are great for indicating "there is no interpolation here" and for strings that embed double-quotes.
I used to think that too. But it doesn’t really help that much, because interpolation is fairly obvious with syntax highlighting. I changed my mind and I prefer consistency, and have every string the same. Also, if you need to add or remove interpolation then you don’t have to change the type of quotes.
Rubocop can autocorrect strings to use the "correct" quotes based on context. The rule for "Standard" is silly and unnecessary. The argument about readability falls flat with me.
At the end of the day, let the tools enforce this nonsense, but I'm still a performance wonk at some level and it drives me crazy seeing interpolatable strings without interpolations.
I was told about a ruby project years ago where they gained a measurable performance boost by converting all the strings without interpolation to single quotes.
That's a vague anecdote so should be taken with a pinch of salt. Even if it was once the case VM often improve to fix these edge cases.
So I was just wondering if there was anything more formal to prove this so that I can avoid this preconception I've been carrying around for years based on nothing more than someone's now dated Lightning Talk.
Theoretically parsing "" should have very little overhead only on parsing, but parsing string is tiny work so it can't be problem. Anyway who cares such performance won't use Ruby.
Yeah, I don't see this having the same sort of diligence around additions (or even the initial ruleset) that would be present in languages with inborn opinions like Go and Rust.
It really seems like a bunch of arbitrary linting rules that this company likes to use, and they are trying to push it on the masses as "Standard", which the uninformed won't understand the nuance of.
I absolutely hate this kind of nitpicking, and am loathe to see it enforced, especially if the org has the bright idea to try to wire this up as a precommit hook.
Single quotes, double quotes, who cares? Oh no, you might have to change some extra characters. Such big cognitive overload, very hard...
All this 'standardization' is stripping the individuality and artistry from writing code. Sometimes I feel like the only person in the world who likes being able to look at code and know who wrote it by the style that they use.
In Ruby, especially, where expressiveness and being a little weird feature so prominently in our cultural heritage. If I wanted to be a conformist I'd write Javascript for a living!
> I absolutely hate this kind of nitpicking, and am loathe to see it enforced, especially if the org has the bright idea to try to wire this up as a precommit hook.
I find this so strange. I also loathe nitpicking about syntax which is precisely why I think this would be a great tool!
I work in JS now on a large team and one of my least favorite activities is trying to find consensus on which linting rules we should/shouldn’t adopt. It’s such a waste of time!
Prettier has been the cause of most arguments about style for JS code I've been involved in recently. For starters, it tends to blow up diffs because you get above/below arbitrary limits and trigger a more extensive reformatting than necessary, and it's infuriating.
I find the argument that it will stop discussion of style bizarre, because it only shuts down discussions about style if you already have the power to tell people what the accepted style for your organisation is. In that case you don't need a tool that refuses to let you pick and choose, you just need the confidence to tell people you're not going to change things.
In other words: It's not Prettier that stops you from having discussions about style again, it's whether or not you signal to people that you're not willing to discuss it. To me, in that respect, a tool like this is a passive aggressive way of signalling that you're unwilling to discuss the subject without being willing to just say that you're not.
Another vote for prettier for JS/TS. The primary projects I work on we made some slight tweaks to the default style (wider line width) and though some people were unhappy about adopting a formatter, there have been zero beefs with prettier's actual output among an opinionated group.
> I find this so strange. I also loathe nitpicking about syntax which is precisely why I think this would be a great tool!
The antidote to nitpicking isn't to force something where nitpicking isn't possible/already resolved, it's staying open-minded and flexible enough to not let the nitpicked things bother you. "There are many roads to Rome" and all that.
In industry, the prevailing code standards are almost certainly wildly divergent from any sort of Ruby "best practice".
In particular, if the goal is to have clear (and therefore somewhat more likely to be robust) code, you're going to see things like the use of single quotes to indicate "this will never be interpolated" or the use of explicit return statements even when "unnecessary" - both of which run afoul of these sorts of highly-opinionated and unconfigurable style enforcers.
I categorically refuse to use tools like this that tries to force a single set of formatting rules, as I've yet to ever see one that hasn't been infuriating in all kinds of ways, because the "things that doesn't matter" to the people building these projects tends to be things that does matter to other peoples sense of what a well formatted program should look like.
As you say, a configurable tool with reasonable defaults to encourage people to only change the things they actually have strong feelings about, fine.
I do a lot of Go (years worth) and whilst I still dislike the standard formatting conventions chosen by `go fmt` I do like that I don't have to be concerned about them at all. For Goland, VSCode, or whatever, I just switch on format-on-save and format-on-paste and I'm good to go (so to speak).
The same with Node. I dislike the output of the (also named 'standard') eslint formatting rules I usually end up using, but by activating the auto-format as above the whole issue is redundant.
In other words, I dislike the format but as long as the code is readable I don't care - though as a writer the aesthetics of the formatted code disappoint me, so I can see both sides.
PS. As an aside the mention of prettier elsewhere makes me shudder. I, too, find that a threshold is reached whereby instead of small localised formatting 'fixes' it decides to change a fair amount more than expected which, as mentioned, makes for unnecessarily convoluted commits.
I avoid Go as much as possible in part because I find its syntax horrible, so I can't really tell whether or not I'd be annoyed by go fmt's formatting if I had to use Go more regularly.
This kind of discussion is the exact reason I want someone to pick the default and make it unconfigurable.
If it's configurable then I'm going to end up wasting time talking about style rather than focusing on functionality. It's the exact reason I've set up my team's code with standard (and Prettier)
It's boring having different Rubocop settings and having people argue over new rules. I have preferences too, but I'd rather get on with my life. I can just write code, and have Standard make it standard and consistent across all projects.
It would be nicer if Ruby did this itself (Crystal does, and that's fantastic) but this is the next best thing. Having one attempted standard is better than no standards at all.
(My only quibble is the name makes it sound related to the Standard JS project when it doesn't).
As someone that is meticulous about writing neatly formatted code without using one of these. I started a new job where they had a medium sized app that had no style guide in place at all, and wow....some people like to add their own “personal touch” to the way they format and style their code but this was just....wow.
It makes such a big difference when you just set it and forget it. It’s not my ideal preference, but holy hell it’s a million times better then what we had before.
an ISO standard that describes a version of ruby that was outdated and in the process of being obsoleted even at the time it was (finally) published. I don't think anyone really worries about that much.
I also had a similar first impression from reading the name of the project. I thought it was going to be related to standardizing Ruby implementations / the Ruby language itself.
It does make itself sound like it's the standard, when it has no relation to either formal (ISO) or living standard (the body of language tests that make multiple compatible Ruby implementations possible).
It's pretentious naming at its worst, IMHO.
And yes, some people might have been looking for language standard and be mislead by this.
I use (and for the most part) really appreciate the JavaScript Standard, which is the inspiration for this. However, while I've thought often about it in Ruby, I'm pretty torn to see it here because of the lack of configuration.
In the JS version they ultimately had to add some configuration because like it or not, there are different cases. Sometimes really strong opinions prevail, and if you are forced to throw the baby out with the bath water because the temperature on the tub is not configurable, you get to a sub optimal outcome.
> For example, Standard requires all string literals be double-quoted. Single-quotes don’t support interpolation but aren’t any more performant, so mixing single & double quoted strings adds a bit of cognitive overhead with zero discernible benefit
The discernible benefit is the reduction of cognitive overhead in understanding if there is any interpolation in the string. At a glance you know whether there are any variables or escape codes to consider.
I will keep writing Ruby how I like it with 3 spaces indentation and double line breaks between methods/classes (yes, I will put multiple classes in one file).
I hate this requirement (and other similar ones). They force the crystallisation of architecture long before the concepts they model have them selves had time to fully crystallise.
You inevitably end up having to shotgun edit a bunch of files (that could have been one file) to re-architect stuff when it changes.
> I hate this requirement (and other similar ones). They force the crystallisation of architecture long before the concepts they model have them selves had time to fully crystallise
I'm not a fan of single-class-per-file as a rigid rule, but it's not my effect that it has any effect on architecture. Adding a file with a new class isn't substantially greater overhead than adding a class in an existing file, and moving stuff between smaller files is, if anything, easier than moving it around within a single monster file.
To me "stardard" ruby style is style used in the std-lib.
Whilst I can see the benefit of having an AST format code for you, e.g. if can you use it to fix language version changes like positional arguments and keyword arguments in Ruby 3,.0 I worry about how good/bad RuboCop is at formatting.
Last time I tried it, it was indenting in a different way to the std-lib.
At the time I found that prettier-ruby[1] did a much better job. Hopefully that's improved since.
I like strongly opinionated formatter/linters like black for Python, but I'm not fond of bogus justifications:
> Single-quotes don’t support interpolation but aren’t any more performant, so mixing single & double quoted strings adds a bit of cognitive overhead with zero discernible benefit
“I can express things that would be interpreted as interpolation in a double-quoted string without escaping” is a discernable benefit.
“I can use literal double-quotes without escaping” is also a discernable benefit.
(Incidentally, this is a case where the justification also makes it unclear whether they've misdescribed the piece they are justifying: the say it requires string literals to be double-quoted but the justification refers only to single- and double-quoted strings. So, does it only ban single-quoted strings, or does it also ban Ruby’s other 6 forms of literals that resolve to strings?)
I use standardrb since I found out about it a year ago. Really like the approach because it doesn't interfere so much with rails generated projects. Take a default rubocop and look at all the style errors you get in rails projects.
Also being a go developer I really appreciate gofmt and the way go code only has one formatted representation.
I am super happy about the leading dots on multi-line method chains which I also voted for. It was a long time in the making, but it gave the project time to consider all the little nuances.
> Obnoxious: come up with a set of style preferences, write some post-hoc justification, and then name it in a way that implies anyone who has different preferences is doing something wrong