8 ms·

A Writer's Ruby

69 points by jjgreen 3y ago

ignurant 3y ago
I usually drink the DHH koolaide when it comes to Rails decisions, but I'm surprised by this decision exactly because of his arguments against being forced to write specific styles. I enjoyed default RuboCop when I was first learning Ruby to gain idiomatic knowledge, and strongly disliked after I took off my training wheels. I don't even like using `standard-rb`, which is a much more tolerant configuration of Rubocop. There are often reasons to disregard certain style rules, and I don't want to ask for permission in `# magic disable comments`. I strongly agree with all of his descriptions of formatting and linting. I also strongly agree with him putting his personal style into Rubocop for the Rails codebase itself, and for project maintainers to be in control of what, if any, style they wish to enforce. But to omakase his style-guide into the consuming projects is surprising and against the very arguments against conforming to style-guides he presents in the first half of the post.
- hakunin 3y ago
  I am in the camp of using as little rubocop as possible, but still using it. I like it to address the drastic stuff like misalignments, mixed tabs and spaces, obvious sloppiness.[1] Still, it should allow most of the freedom. My preferences are posted in what I call a "narrative" Rails template[2]. It's a relaxed "standardrb", which I have since relaxed even further, but haven't updated the repo yet. [1]: https://github.com/AuthorizeNet/sdk-ruby/commit/1972b153a89346613367cc90f363126ad4dea12b https://github.com/AuthorizeNet/sdk-ruby/commit/1972b153a893... [2]: https://github.com/maxim/narrative/blob/main/example_app/.rubocop.yml https://github.com/maxim/narrative/blob/main/example_app/.ru...
  - kawsper 3y ago
    Rubocop is not just styling, it can also be used to catch mistakes and subtle bugs: http://kaspergrubbe.com/enforcing-host-parameter-usage-for-urls-in-e-mail-templates-with-hamlcop http://kaspergrubbe.com/enforcing-host-parameter-usage-for-u...
- jaynetics 3y ago
  I always slap relaxed.ruby.style on every new project that uses rubocop. It disables all the excessive rules. https://github.com/janlelis/relaxed.ruby.style https://github.com/janlelis/relaxed.ruby.style
pelagicAustral 3y ago
I've read this twice and I'm still getting something like: "Programmers lack style, hence linters, but linters are draconian in nature, so we are going to slap a linter in the next release" It is Friday and I'm tired, so maybe I need another re-read.
- Alifatisk 3y ago
  I think DHH explains the reason pretty well in the article > That’s why we’re shipping a default linter, cleverly called RuboCop, in the next version of Rails. Not such that I, or anyone, can mandate what style your codebase ought to be written in, but such that you can find and enforce your own. So every new Rails project has preset of linting style, which defaults to whatever the Rails team chose, but the point is that people are free to adjust the config file to whatever they prefer. So the same style is applied through the codebase.
  - pelagicAustral 3y ago
    No, that's all peachy, but you're just going to tell me the post doesn't start with one idea, smoothly moves on, and just past the code example, wraps it up by completely dismantling the premise?
    - lcnPylGDnU4H9OF 3y ago
      > but linters are draconian in nature His point is actually that linters lacking configuration are draconian. > Some languages, like Go, have a built-in linter, which applies a universal style that’s been set by the language designers. That’s the most totalitarian approach. I'd doubt it's the "built-in" aspect; it sounds quite a bit like it's the "universal style" that the author doesn't like.
- deleted 3y ago
  [deleted]
- maxsilver 3y ago
  (this is probably unfairly cynical but), reading heavily between the lines, this reads to me like DHH noticed lots of Rails folks and rubyists already like and use "standardrb" for this https://github.com/standardrb/standard https://github.com/standardrb/standard -- https://www.youtube.com/watch?v=QVilOzkLdlI https://www.youtube.com/watch?v=QVilOzkLdlI -- but for some (unspecified?) reason(s), wasn't willing to bless the popular community-created universal standard as default convention, so instead wrote up his own, and is declaring his the default convention for Rails.
smithcoin 3y ago
> gofmt bothers me > we're shipping rubocop with the next rails > choose one I'm a pretty big DHH fanboy, but this article felt pretty odd in its tone and composure.
- smugglerFlynn 3y ago
  I read it as “different teams have different styles, so they might benefit from having a tool to enforce their own styles” - hence the Rubocop
  - ysavir 3y ago
    Yeah, but nothing he said supports the idea of having rules applied automatically unless they configure rubocop. Everything he said supports an opt-in methodology (and maybe it will be, by requiring a flag when starting a new project), but putting every programmer and team in a place where they have to configure rubocop on their rails projects is counter to the tone and points he makes in the article.
mrinterweb 3y ago
When you can look at some code in a repo and immediately know who wrote it, that is usually a problem. I've worked in code bases where the devs could not agree on style and they each did their own thing. It quickly became an unmaintainable mess. Having a homogeneous code style is a good step towards long term maintainability. It has been many years since I've worked on a rails repo that didn't have rubocop. Glad to hear rails will ship with rubocop.
- leecommamichael 3y ago
  I can't quite imagine what you mean by this, asking for clarification sorry if I come off wrong. Why is it a problem that you know who wrote the code by looking at it? Do you mean that their style is distracting?
  - kevinmchugh 3y ago
    Ruby has "reduce" and "inject" aliased. Most developers pick one or the other. A codebase that mixes them adds cognitive load. It's not hard, but it adds a speed bump to understanding.
    - ysavir 3y ago
      Does it really, though? How much time do you actually lose to having to sometimes read "reduce" and sometimes read "inject"? I've heard these arguments a hundred times, and not once did I feel like the underlying sentiment was more than "I like/dislike X, therefor I want to limit how much other people can use X".
      - kevinmchugh 3y ago
        I worked on a small team for years and the other person who was there that whole time was an inject guy. I'm a reduce guy. It's fine, we never tried to change each other, but I never got over the mental hump of "what does inject do? Oh right". This is for the smallest possible style difference. I agree that a lot of folks get hung up on their personal preferences and want to fight about. Linters reduce those fights, and encourage everybody to just deal with it.
notpachet 3y ago
If you're just writing code for yourself, well and good, do whatever pleases you. The problem is that, as George Costanza said, we are living in a society. If you work on code that other people need to read and maintain, then there are a few individual concessions we should consider in order to benefit the larger group. In addition to linting, I'd also put types in this bucket. I don't think it's a coincidence that DHH doesn't like the way those feel, either. They may cut into your personal enjoyment, but if it benefits the productivity of the larger group then that's a sacrifice you should probably consider. This is the entire reason that standards exist.
thibaut_barrere 3y ago
« Some languages, like Go, have a built-in linter, which applies a universal style that’s been set by the language designers. That’s the most totalitarian approach. A decree on what a program should look like that’s barely two feet removed from a compile error. I don’t like that one bit. It reminds me of Newspeak, the new INGSOC language from Orwell’s 1984. » I do not like something hence it’s totalitarian and newspeak. Excellent material for some courses on discourse analysis!
- leecommamichael 3y ago
  Formatters are an interesting topic in that sense. Anecdotally, I sense that they're usually introduced to stem debates about style. I think that's probably not a good enough reason for them to exist. There's a sensibility that says "debates about style are bad and wrong." Where is that coming from? Why is that opinion so pervasive?
  - RangerScience 3y ago
    AFAIK, it's because they can easily become toxic and immensely time-consuming. Personally, I haven't seen that failure mode, although I also haven't been in a situation where it'd come up.
  - thibaut_barrere 3y ago
    I don't know, but I must say that in Elixir, I really enjoy the built-in formatter (https://hexdocs.pm/mix/1.14/Mix.Tasks.Format.html https://hexdocs.pm/mix/1.14/Mix.Tasks.Format.html). It really is a non-event in most codebases I've worked with. Really happy that this exist and is a core aspect of the language now.
  - wiseowise 3y ago
    Maybe because they’re unproductive, bring no value and generally a team drain because every special snowflake feels like their specific vision is the readable one?
andrewpolidori 3y ago
The benefit of gofmt has nothing to do with "style" per se. Because it's standardized, tools can rely on its output. This means that you can easily write tools that handle go source code and interoperate well with each other
- leecommamichael 3y ago
  Go's parser can be used on code with any formatting.
  - andrewpolidori 3y ago
    True, but there are times when doing some analyzes or refactoring that what one wants to operate on is go source directly, so the output of gofmt is easier and standardized and doesn't require handling the ast at all.
    - ammar2 3y ago
      Can you give an example of such a tool that analyzes/refactors just the text output of gofmt? It seems like that approach that would be fraught with errors considering how lenient gofmt can be at times but maybe it would be okay for simple stuff. e.g all of these ways of invoking methods: fmt. Println("Hello ", "World", ) fmt.Println("Hello ", "World") fmt.Println("Hello ", "World")
- wavemode 3y ago
  Do you have a source for this? It's always been my understanding that the creation of gofmt was almost entirely so that programmers would stop arguing about style.
  - andrewpolidori 3y ago
    Sorry I didn't mean to imply that wasn't a driving factor of it's creation. I should've said that it's a useful side effect
killthebuddha 3y ago
This post is so wonderfully confused it's throwing my brain into an infinite loop. Misunderstanding newspeak, then a howler of a non sequitur, all about elegant composition, all the while turning a simple announcement into a super clunky argument. It's perfect doublespeak, the kind of language that throws critical thinking into infinite loops.
- pebble 3y ago
  He didn't even bother to proofread this so what do you expect.
  - jmknoll 3y ago
    Should have used a linter
    - wiseowise 3y ago
      What for, he’d probably configure it to his unique and expressive style.
- tessierashpool 3y ago
  DHH imposes this kind of cognitive dissonance on the Ruby community at a pretty regular interval. it's generally worth it, but it's still a kind of brain tax.
- why-el 3y ago
  newspeak is for dramatic (and dare I say, rather fun) effect. I think his point is straightforward and not confused: one style and one liner for the entire programming language prohibits personal expression of style. A linter to enforce your own personal / team styles is a good idea. I don't see the confusion. You might disagree with one or both, but to me it seems logically consistent with the premise of the article which is that personal style is important in programming.
  - sebastianconcpt 3y ago
leecommamichael 3y ago
Arguments of style are our desire for this work to be easier turning us against one another. We write our statements for both human and machine colleagues (who will never see eye-to-eye.) I regret that formatters can prevent us from laying things out most clearly at times. Formatters feel varying levels of painful on a per-language basis. The balance probably lies in empathy: It wasn't best to write it that way if it was not beneficial to either the machine or your collaborators. On the other hand, if it brings someone joy to write in their distinct style, would we deny that joy?
devrob 3y ago
Side tangent: I love Ruby, but strongly dislike and discourage `unless` in the code base. It still trips me up having written Ruby 5 years at this stage. Maybe its just me but I still pause every time for myself when looking at `unless` with a multi conditional. Example: def do_the_thing return do_not_do_it unless first_conditional || second_conditional okay_actually_do_it end Glad that Rubocop is shipping with Rails though!
- hahahacorn 3y ago
  Same. I encourage the use of unless iff it reads like english and I’ve found that to be a pretty good rule of thumb for the majority of my team
- kevinmchugh 3y ago
  I've known a handful of people who can handle conditionals inside an unless, and dozens who can't. I'm in the latter camp. Banning conditionals in an unless is a very reasonable rule to follow
- maxsilver 3y ago
  Maybe a decade of doing ruby has rotted my brain, but I love `unless`, and use it often. Yes, every `unless` could be rewritten with an `if` instead, certainly. But I like the implication of weight these keywords carry in English language. `unless` implies it's a minor condition, that the majority of runs should fall on the opposite side of the conditional, where as `if` does not -- both weights of the condition feel potentially equivilant-ish.
- psadauskas 3y ago
  `unless` is great, but best used sparingly. Only use it if the conditional is single, and simple. Never use it with `&&` or `||`, or `!`. `unless admin?` is fine `unless !admin?` is annoying `unless user.admin? && account.support?` leads to madness
MattyMc 3y ago
Nearly all the first comments express that the justification to include Rubocop with a default rule set in Rails 8 contradicts DHH's criticism of languages such as Go which have a built-in linter, therefore dictating style rules to programmers. DHH criticizes Go's approach as totalitarian while shipping Rubocop with Basecamp's rule set. Rubocop is a linter (etc) whose rule set can be easily customized and to include it in Rails wouldn't be possible without _some_ default set of rules. DHH addresses this apparent contradiction directly, too: "Not such that I, or anyone, can mandate what style your codebase ought to be written in, but such that you can find and enforce your own." I'm reading: A linter/formatter will be included in Rails 8 with a smart default rule set, and it can be easily customized. I don't see any contradiction. I'm highly aligned with this decision as it could help alleviate a recurring pain point at our tiny company: managing code formatters and linters in our IDE (Solargraph, Rubocop, Ruby LSP, etc). Further, I'd expect excellent documentation on how we can customize the rules to best suit our purposes, too.
hakunin 3y ago
Most counterarguments go something like "It's bad when everyone writes in their own style, that's why one style should be enforced." But this gets you right into the other extreme: code consistency is valued above comprehensibility. Now your code is harder to read because you format it mechanically, instead of using your own human consideration. The right answer in my view is kind of what I think DHH is trying to get at: have enough rules to avoid straight up sloppiness and clear no-nos. Don't have any rules that might change based on human consideration.
- wiseowise 3y ago
  > Now your code is harder to read because you format it mechanically, instead of using your own human consideration. How so?
  - hakunin 3y ago
    Because humans can break a rule in favor of readability, symmetry, clarity. Linter can't.
    - wiseowise 3y ago
      > Because humans can break a rule in favor of readability, symmetry, clarity. Care to show examples? I haven’t encountered a single one where that would the case.
      - hakunin 3y ago
        With Ruby, you have many different, expressive ways of saying the same thing. Examples that come to mind off the top of my head: deciding to vertically align keyword arguments sometimes. Wrapping code differently to meet a line length limit. Breaking the rule of "never making a variable one letter long" in tiny, clear code snippets to make everything read better. Choosing to use double vs single quotes (single quotes signal that the string has no interpolation). Putting a space at the start/end of array and hash literals in some cases. Using .call() or .() or [] to call a lambda. There are many other little things like that. Each one seems insignificant, but together they replace all human consideration. And since Ruby is very concise and efficient (small amount of code gets a lot done), expressing your "hows", "whats", and "whys"[1] in the most readable way should be where you spend some of your time. [1]: https://max.engineer/maintainable-code https://max.engineer/maintainable-code
sebastianconcpt 3y ago
I feel the same here but not just for Ruby. I also experienced it in Smalltalk where you can achieve wonderful levels of expressivity. https://www.amazon.com/Smalltalk-Style-Suzanne-Skublics/dp/0131655493 https://www.amazon.com/Smalltalk-Style-Suzanne-Skublics/dp/0...
siliconc0w 3y ago
One reason I don't like Ruby is because of the numerous ways to do things - stylistic consistency makes code easier to read and gofmt gives you a universal baseline for that consistency. So I guess this is a good thing but yeah it's weird argument. I guess the key is that this is provided as optional take-or-leave situation vs the tyranny of gofmt. Maybe in the future we can just check-in the AST and a LLM will show us the code in whatever style it knows we like best.
- lcnPylGDnU4H9OF 3y ago
  > I guess the key is that this is provided as optional take-or-leave situation It's a bit more than take-or-leave. Rubocop is configurable so individual projects could have their own style, no enforced style, or the default style.
  - jjgreen 3y ago
    It is, but how much time do you want to commit to setting it up "just right"? I don't like it because the defaults are so authoritarian -- if it can be proscribed it is -- one of the few times that Python beats Ruby hands-down, pycodestyle/pep8 is a linting Amsterdam to RuboCop's North Korea.
    - wiseowise 3y ago
      Sorry, there’s only one true formatter in Python and that’s Black.
  - scruple 3y ago
    That Go proverb comes to mind: "gofmt's style is nobody's favorite, but gofmt is everybody's favorite." And I don't like gofmt's output, personally, but I immediately saw the benefit to community-wide adoption specifically because of my experiences with Ruby and RoR and every project having it's own specific little (typically also totalitarian, very teapot dictator in my experience) set of StyleCop configurations. Frankly, there's a high level of bikeshedding that can open yourself up to with configurable linters that I'm too old to give a shit about. edit/ I have no horse in this race, either... I use neither of these languages today professionally.
kevinmchugh 3y ago
One thing I like about prettier and gofmt is that there's no exceptions to the rules. You get what's there. RuboCop allows annotations to exclude a bit of code from the rules. This makes the code very unpleasant to read, because you have lines exclusively for the computer to read littered amongst everything else. It looks like this and I hate it: https://docs.rubocop.org/rubocop/1.59/configuration.html#disabling-cops-within-source-code https://docs.rubocop.org/rubocop/1.59/configuration.html#dis... Edit to add: I had experience years ago with RuboCop's auto correct making a breaking change, so I decided to distrust it. Be careful letting it change your source code.
prh8 3y ago
TLDR: Rails is shipping a linter config by default in the future
deleted 3y ago
[deleted]
romafirst3 3y ago
Article is awful but linters are amazing and default linting is beautiful. If you’ve coded as long as I have you’ll remember the endless bike shedding about style and random garbage that ended up in code bases. 2 spaces in a tab or 4? Who gives a shit. My opinion is I don’t care what the style is so long as it’s consistent.
deleted 3y ago
[deleted]
wiseowise 3y ago
Oh Jesus Christ, here we go again. > Imagine every novel written in the same style, Hemingway indistinguishable from Dickens, Tolkien from Rowling. It would be awfully gray to enjoy the English language if there was only a single shade of prose. Code is not a novel and your run off the mill developer is NOT Hemingway, Tolkien or Rowling. Code is a plumbing, nothing more, nothing less.
agounaris 3y ago
Starting with the example, I find it counterproductive because our brains are always going for the condition first. (or my brain) Waiting on a traffic light the thinking is "if light is red/green, then wait/cross" its not like "don't cross unless its green". Also if there is only one obvious way to do things it's a productivity boost! I cannot stress enough how many times we have debated coding styles, wasting precious development time! No customer cares of your coding style! If you are an engineering who cares more about the length of a line or the import order instead of a critical feature for the customer, you have to rethink the priorities.
sebastianconcpt 3y ago
I'm still thinking about this on code style and what produces on the developers. In one hand if the medium enforces a pre fabricated style, that's not an issue among other developers anymore and a guaranteed reading style convention for all which is confort for all. In the other hand, if the medium allows your own style, there is space created to become emotionally attached to unique coding styles. As a preliminary conclusion, in this regard, would be to say, to what degree you value freedom of coder's expression versus commoditization of coder's work? For libraries the answer is way less controversial. For your own apps in a tight group of very culturally aligned and productive Band of Brothers coders? Is not that clear.

69 points by jjgreen 3y ago

I usually drink the DHH koolaide when it comes to Rails decisions, but I'm surprised by this decision exactly because of his arguments against being forced to write specific styles. I enjoyed default RuboCop when I was first learning Ruby to gain idiomatic knowledge, and strongly disliked after I took off my training wheels. I don't even like using `standard-rb`, which is a much more tolerant configuration of Rubocop. There are often reasons to disregard certain style rules, and I don't want to ask for permission in `# magic disable comments`. I strongly agree with all of his descriptions of formatting and linting. I also strongly agree with him putting his personal style into Rubocop for the Rails codebase itself, and for project maintainers to be in control of what, if any, style they wish to enforce. But to omakase his style-guide into the consuming projects is surprising and against the very arguments against conforming to style-guides he presents in the first half of the post.

hakunin 3y ago
I am in the camp of using as little rubocop as possible, but still using it. I like it to address the drastic stuff like misalignments, mixed tabs and spaces, obvious sloppiness.[1] Still, it should allow most of the freedom. My preferences are posted in what I call a "narrative" Rails template[2]. It's a relaxed "standardrb", which I have since relaxed even further, but haven't updated the repo yet. [1]: https://github.com/AuthorizeNet/sdk-ruby/commit/1972b153a89346613367cc90f363126ad4dea12b https://github.com/AuthorizeNet/sdk-ruby/commit/1972b153a893... [2]: https://github.com/maxim/narrative/blob/main/example_app/.rubocop.yml https://github.com/maxim/narrative/blob/main/example_app/.ru...
- kawsper 3y ago
  Rubocop is not just styling, it can also be used to catch mistakes and subtle bugs: http://kaspergrubbe.com/enforcing-host-parameter-usage-for-urls-in-e-mail-templates-with-hamlcop http://kaspergrubbe.com/enforcing-host-parameter-usage-for-u...
jaynetics 3y ago
I always slap relaxed.ruby.style on every new project that uses rubocop. It disables all the excessive rules. https://github.com/janlelis/relaxed.ruby.style https://github.com/janlelis/relaxed.ruby.style

pelagicAustral 3y ago

I've read this twice and I'm still getting something like: "Programmers lack style, hence linters, but linters are draconian in nature, so we are going to slap a linter in the next release" It is Friday and I'm tired, so maybe I need another re-read.

Alifatisk 3y ago
I think DHH explains the reason pretty well in the article > That’s why we’re shipping a default linter, cleverly called RuboCop, in the next version of Rails. Not such that I, or anyone, can mandate what style your codebase ought to be written in, but such that you can find and enforce your own. So every new Rails project has preset of linting style, which defaults to whatever the Rails team chose, but the point is that people are free to adjust the config file to whatever they prefer. So the same style is applied through the codebase.
- pelagicAustral 3y ago
  No, that's all peachy, but you're just going to tell me the post doesn't start with one idea, smoothly moves on, and just past the code example, wraps it up by completely dismantling the premise?
  - lcnPylGDnU4H9OF 3y ago
    > but linters are draconian in nature His point is actually that linters lacking configuration are draconian. > Some languages, like Go, have a built-in linter, which applies a universal style that’s been set by the language designers. That’s the most totalitarian approach. I'd doubt it's the "built-in" aspect; it sounds quite a bit like it's the "universal style" that the author doesn't like.
deleted 3y ago
[deleted]
maxsilver 3y ago
(this is probably unfairly cynical but), reading heavily between the lines, this reads to me like DHH noticed lots of Rails folks and rubyists already like and use "standardrb" for this https://github.com/standardrb/standard https://github.com/standardrb/standard -- https://www.youtube.com/watch?v=QVilOzkLdlI https://www.youtube.com/watch?v=QVilOzkLdlI -- but for some (unspecified?) reason(s), wasn't willing to bless the popular community-created universal standard as default convention, so instead wrote up his own, and is declaring his the default convention for Rails.

smithcoin 3y ago

> gofmt bothers me > we're shipping rubocop with the next rails > choose one I'm a pretty big DHH fanboy, but this article felt pretty odd in its tone and composure.

smugglerFlynn 3y ago
I read it as “different teams have different styles, so they might benefit from having a tool to enforce their own styles” - hence the Rubocop
- ysavir 3y ago
  Yeah, but nothing he said supports the idea of having rules applied automatically unless they configure rubocop. Everything he said supports an opt-in methodology (and maybe it will be, by requiring a flag when starting a new project), but putting every programmer and team in a place where they have to configure rubocop on their rails projects is counter to the tone and points he makes in the article.

mrinterweb 3y ago

When you can look at some code in a repo and immediately know who wrote it, that is usually a problem. I've worked in code bases where the devs could not agree on style and they each did their own thing. It quickly became an unmaintainable mess. Having a homogeneous code style is a good step towards long term maintainability. It has been many years since I've worked on a rails repo that didn't have rubocop. Glad to hear rails will ship with rubocop.

leecommamichael 3y ago
I can't quite imagine what you mean by this, asking for clarification sorry if I come off wrong. Why is it a problem that you know who wrote the code by looking at it? Do you mean that their style is distracting?
- kevinmchugh 3y ago
  Ruby has "reduce" and "inject" aliased. Most developers pick one or the other. A codebase that mixes them adds cognitive load. It's not hard, but it adds a speed bump to understanding.
  - ysavir 3y ago
    Does it really, though? How much time do you actually lose to having to sometimes read "reduce" and sometimes read "inject"? I've heard these arguments a hundred times, and not once did I feel like the underlying sentiment was more than "I like/dislike X, therefor I want to limit how much other people can use X".
    - kevinmchugh 3y ago
      I worked on a small team for years and the other person who was there that whole time was an inject guy. I'm a reduce guy. It's fine, we never tried to change each other, but I never got over the mental hump of "what does inject do? Oh right". This is for the smallest possible style difference. I agree that a lot of folks get hung up on their personal preferences and want to fight about. Linters reduce those fights, and encourage everybody to just deal with it.

notpachet 3y ago

If you're just writing code for yourself, well and good, do whatever pleases you. The problem is that, as George Costanza said, we are living in a society. If you work on code that other people need to read and maintain, then there are a few individual concessions we should consider in order to benefit the larger group. In addition to linting, I'd also put types in this bucket. I don't think it's a coincidence that DHH doesn't like the way those feel, either. They may cut into your personal enjoyment, but if it benefits the productivity of the larger group then that's a sacrifice you should probably consider. This is the entire reason that standards exist.

thibaut_barrere 3y ago

« Some languages, like Go, have a built-in linter, which applies a universal style that’s been set by the language designers. That’s the most totalitarian approach. A decree on what a program should look like that’s barely two feet removed from a compile error. I don’t like that one bit. It reminds me of Newspeak, the new INGSOC language from Orwell’s 1984. » I do not like something hence it’s totalitarian and newspeak. Excellent material for some courses on discourse analysis!

leecommamichael 3y ago
Formatters are an interesting topic in that sense. Anecdotally, I sense that they're usually introduced to stem debates about style. I think that's probably not a good enough reason for them to exist. There's a sensibility that says "debates about style are bad and wrong." Where is that coming from? Why is that opinion so pervasive?
- RangerScience 3y ago
  AFAIK, it's because they can easily become toxic and immensely time-consuming. Personally, I haven't seen that failure mode, although I also haven't been in a situation where it'd come up.
- thibaut_barrere 3y ago
  I don't know, but I must say that in Elixir, I really enjoy the built-in formatter (https://hexdocs.pm/mix/1.14/Mix.Tasks.Format.html https://hexdocs.pm/mix/1.14/Mix.Tasks.Format.html). It really is a non-event in most codebases I've worked with. Really happy that this exist and is a core aspect of the language now.
- wiseowise 3y ago
  Maybe because they’re unproductive, bring no value and generally a team drain because every special snowflake feels like their specific vision is the readable one?

andrewpolidori 3y ago

The benefit of gofmt has nothing to do with "style" per se. Because it's standardized, tools can rely on its output. This means that you can easily write tools that handle go source code and interoperate well with each other

leecommamichael 3y ago
Go's parser can be used on code with any formatting.
- andrewpolidori 3y ago
  True, but there are times when doing some analyzes or refactoring that what one wants to operate on is go source directly, so the output of gofmt is easier and standardized and doesn't require handling the ast at all.
  - ammar2 3y ago
    Can you give an example of such a tool that analyzes/refactors just the text output of gofmt? It seems like that approach that would be fraught with errors considering how lenient gofmt can be at times but maybe it would be okay for simple stuff. e.g all of these ways of invoking methods: fmt. Println("Hello ", "World", ) fmt.Println("Hello ", "World") fmt.Println("Hello ", "World")
wavemode 3y ago
Do you have a source for this? It's always been my understanding that the creation of gofmt was almost entirely so that programmers would stop arguing about style.
- andrewpolidori 3y ago
  Sorry I didn't mean to imply that wasn't a driving factor of it's creation. I should've said that it's a useful side effect

killthebuddha 3y ago

This post is so wonderfully confused it's throwing my brain into an infinite loop. Misunderstanding newspeak, then a howler of a non sequitur, all about elegant composition, all the while turning a simple announcement into a super clunky argument. It's perfect doublespeak, the kind of language that throws critical thinking into infinite loops.

pebble 3y ago
He didn't even bother to proofread this so what do you expect.
- jmknoll 3y ago
  Should have used a linter
  - wiseowise 3y ago
    What for, he’d probably configure it to his unique and expressive style.
tessierashpool 3y ago
DHH imposes this kind of cognitive dissonance on the Ruby community at a pretty regular interval. it's generally worth it, but it's still a kind of brain tax.
why-el 3y ago
newspeak is for dramatic (and dare I say, rather fun) effect. I think his point is straightforward and not confused: one style and one liner for the entire programming language prohibits personal expression of style. A linter to enforce your own personal / team styles is a good idea. I don't see the confusion. You might disagree with one or both, but to me it seems logically consistent with the premise of the article which is that personal style is important in programming.
- sebastianconcpt 3y ago

leecommamichael 3y ago

Arguments of style are our desire for this work to be easier turning us against one another. We write our statements for both human and machine colleagues (who will never see eye-to-eye.) I regret that formatters can prevent us from laying things out most clearly at times. Formatters feel varying levels of painful on a per-language basis. The balance probably lies in empathy: It wasn't best to write it that way if it was not beneficial to either the machine or your collaborators. On the other hand, if it brings someone joy to write in their distinct style, would we deny that joy?

devrob 3y ago

Side tangent: I love Ruby, but strongly dislike and discourage `unless` in the code base. It still trips me up having written Ruby 5 years at this stage. Maybe its just me but I still pause every time for myself when looking at `unless` with a multi conditional. Example: def do_the_thing return do_not_do_it unless first_conditional || second_conditional okay_actually_do_it end Glad that Rubocop is shipping with Rails though!

hahahacorn 3y ago
Same. I encourage the use of unless iff it reads like english and I’ve found that to be a pretty good rule of thumb for the majority of my team
kevinmchugh 3y ago
I've known a handful of people who can handle conditionals inside an unless, and dozens who can't. I'm in the latter camp. Banning conditionals in an unless is a very reasonable rule to follow
maxsilver 3y ago
Maybe a decade of doing ruby has rotted my brain, but I love `unless`, and use it often. Yes, every `unless` could be rewritten with an `if` instead, certainly. But I like the implication of weight these keywords carry in English language. `unless` implies it's a minor condition, that the majority of runs should fall on the opposite side of the conditional, where as `if` does not -- both weights of the condition feel potentially equivilant-ish.
psadauskas 3y ago
`unless` is great, but best used sparingly. Only use it if the conditional is single, and simple. Never use it with `&&` or `||`, or `!`. `unless admin?` is fine `unless !admin?` is annoying `unless user.admin? && account.support?` leads to madness

MattyMc 3y ago

Nearly all the first comments express that the justification to include Rubocop with a default rule set in Rails 8 contradicts DHH's criticism of languages such as Go which have a built-in linter, therefore dictating style rules to programmers. DHH criticizes Go's approach as totalitarian while shipping Rubocop with Basecamp's rule set. Rubocop is a linter (etc) whose rule set can be easily customized and to include it in Rails wouldn't be possible without _some_ default set of rules. DHH addresses this apparent contradiction directly, too: "Not such that I, or anyone, can mandate what style your codebase ought to be written in, but such that you can find and enforce your own." I'm reading: A linter/formatter will be included in Rails 8 with a smart default rule set, and it can be easily customized. I don't see any contradiction. I'm highly aligned with this decision as it could help alleviate a recurring pain point at our tiny company: managing code formatters and linters in our IDE (Solargraph, Rubocop, Ruby LSP, etc). Further, I'd expect excellent documentation on how we can customize the rules to best suit our purposes, too.

hakunin 3y ago

Most counterarguments go something like "It's bad when everyone writes in their own style, that's why one style should be enforced." But this gets you right into the other extreme: code consistency is valued above comprehensibility. Now your code is harder to read because you format it mechanically, instead of using your own human consideration. The right answer in my view is kind of what I think DHH is trying to get at: have enough rules to avoid straight up sloppiness and clear no-nos. Don't have any rules that might change based on human consideration.

wiseowise 3y ago
> Now your code is harder to read because you format it mechanically, instead of using your own human consideration. How so?
- hakunin 3y ago
  Because humans can break a rule in favor of readability, symmetry, clarity. Linter can't.
  - wiseowise 3y ago
    > Because humans can break a rule in favor of readability, symmetry, clarity. Care to show examples? I haven’t encountered a single one where that would the case.
    - hakunin 3y ago
      With Ruby, you have many different, expressive ways of saying the same thing. Examples that come to mind off the top of my head: deciding to vertically align keyword arguments sometimes. Wrapping code differently to meet a line length limit. Breaking the rule of "never making a variable one letter long" in tiny, clear code snippets to make everything read better. Choosing to use double vs single quotes (single quotes signal that the string has no interpolation). Putting a space at the start/end of array and hash literals in some cases. Using .call() or .() or [] to call a lambda. There are many other little things like that. Each one seems insignificant, but together they replace all human consideration. And since Ruby is very concise and efficient (small amount of code gets a lot done), expressing your "hows", "whats", and "whys"[1] in the most readable way should be where you spend some of your time. [1]: https://max.engineer/maintainable-code https://max.engineer/maintainable-code

sebastianconcpt 3y ago

I feel the same here but not just for Ruby. I also experienced it in Smalltalk where you can achieve wonderful levels of expressivity. https://www.amazon.com/Smalltalk-Style-Suzanne-Skublics/dp/0131655493 https://www.amazon.com/Smalltalk-Style-Suzanne-Skublics/dp/0...

siliconc0w 3y ago

One reason I don't like Ruby is because of the numerous ways to do things - stylistic consistency makes code easier to read and gofmt gives you a universal baseline for that consistency. So I guess this is a good thing but yeah it's weird argument. I guess the key is that this is provided as optional take-or-leave situation vs the tyranny of gofmt. Maybe in the future we can just check-in the AST and a LLM will show us the code in whatever style it knows we like best.

lcnPylGDnU4H9OF 3y ago
> I guess the key is that this is provided as optional take-or-leave situation It's a bit more than take-or-leave. Rubocop is configurable so individual projects could have their own style, no enforced style, or the default style.
- jjgreen 3y ago
  It is, but how much time do you want to commit to setting it up "just right"? I don't like it because the defaults are so authoritarian -- if it can be proscribed it is -- one of the few times that Python beats Ruby hands-down, pycodestyle/pep8 is a linting Amsterdam to RuboCop's North Korea.
  - wiseowise 3y ago
    Sorry, there’s only one true formatter in Python and that’s Black.
- scruple 3y ago
  That Go proverb comes to mind: "gofmt's style is nobody's favorite, but gofmt is everybody's favorite." And I don't like gofmt's output, personally, but I immediately saw the benefit to community-wide adoption specifically because of my experiences with Ruby and RoR and every project having it's own specific little (typically also totalitarian, very teapot dictator in my experience) set of StyleCop configurations. Frankly, there's a high level of bikeshedding that can open yourself up to with configurable linters that I'm too old to give a shit about. edit/ I have no horse in this race, either... I use neither of these languages today professionally.

kevinmchugh 3y ago

One thing I like about prettier and gofmt is that there's no exceptions to the rules. You get what's there. RuboCop allows annotations to exclude a bit of code from the rules. This makes the code very unpleasant to read, because you have lines exclusively for the computer to read littered amongst everything else. It looks like this and I hate it: https://docs.rubocop.org/rubocop/1.59/configuration.html#disabling-cops-within-source-code https://docs.rubocop.org/rubocop/1.59/configuration.html#dis... Edit to add: I had experience years ago with RuboCop's auto correct making a breaking change, so I decided to distrust it. Be careful letting it change your source code.

prh8 3y ago

TLDR: Rails is shipping a linter config by default in the future

deleted 3y ago

[deleted]

romafirst3 3y ago

Article is awful but linters are amazing and default linting is beautiful. If you’ve coded as long as I have you’ll remember the endless bike shedding about style and random garbage that ended up in code bases. 2 spaces in a tab or 4? Who gives a shit. My opinion is I don’t care what the style is so long as it’s consistent.

deleted 3y ago

[deleted]

wiseowise 3y ago

Oh Jesus Christ, here we go again. > Imagine every novel written in the same style, Hemingway indistinguishable from Dickens, Tolkien from Rowling. It would be awfully gray to enjoy the English language if there was only a single shade of prose. Code is not a novel and your run off the mill developer is NOT Hemingway, Tolkien or Rowling. Code is a plumbing, nothing more, nothing less.

agounaris 3y ago

Starting with the example, I find it counterproductive because our brains are always going for the condition first. (or my brain) Waiting on a traffic light the thinking is "if light is red/green, then wait/cross" its not like "don't cross unless its green". Also if there is only one obvious way to do things it's a productivity boost! I cannot stress enough how many times we have debated coding styles, wasting precious development time! No customer cares of your coding style! If you are an engineering who cares more about the length of a line or the import order instead of a critical feature for the customer, you have to rethink the priorities.

sebastianconcpt 3y ago

I'm still thinking about this on code style and what produces on the developers. In one hand if the medium enforces a pre fabricated style, that's not an issue among other developers anymore and a guaranteed reading style convention for all which is confort for all. In the other hand, if the medium allows your own style, there is space created to become emotionally attached to unique coding styles. As a preliminary conclusion, in this regard, would be to say, to what degree you value freedom of coder's expression versus commoditization of coder's work? For libraries the answer is way less controversial. For your own apps in a tight group of very culturally aligned and productive Band of Brothers coders? Is not that clear.