Elixir is pretty good at this. I've found it really easy to do a (useful) drive-by pr on someone's open source code, for example, so that's with almost no context whatsoever.

Nobody writes code like the op though (I'm pretty sure it's satire)

I think having a tool to standardise formatting is huge, and a lot of what makes Elixir code easy to read is mix format.

That and the fact most of the community started out with similar ideas on good code, so there was less bikeshedding around formatting.

I have to disagree on this point.

Formatting could be beneficial, but it gets abused so fast that it becomes a problem.

First thing, no one challenges the choices made by the formatter, which is a problem in the long term. The other thing is how far the formatter goes. Rubocop in ruby is a clear example of this, they went way too far with it and producing a readable rspec test is impossible without violating at least one of the rules.

A few days ago, I ended up writing something along these lines:

```

def something err, obj1 = dependency1.call(someargs) return err, obj1 if err.nil?

  err, obj2 = dependency2.call(obj1) 
  return err, obj2 if err.nil?

  err, obj3 = dependency3.call(obj2) 
  return err, obj3 if err.nil?

  err, obj4 = dependency4.call(obj3) 
  return err, obj4 if err.nil?

  err, obj5 = dependency5.call(obj4) 
  return err, obj5 if err.nil?

  [nil, obj5]

end

```

This is a pipeline, to a human being it looks simple because the "return line" after reading the first time and understanding it's an early exit in case of errors, it's identical in all 5 steps. Human brain just excludes those returns after having read the first one.

Rubocop however claims that there is too much complexity going on here due to 5 if branches. That's a machine reading the code.

If I have to rewrite the code according to rubocop standards, it ends up being a lot less readable and with a lot more indirection for no particular advantage.

I find it funny, we use styleguides to ease human interactions with code, but we let the machine evaluating that. It's problematic, the machine doesn't see the code as us.

Edit: My bad didn't recognize the parent comment was about Ruby, and that the code isn't elixir by a long way.

Correct me if I'm wrong but I think there are 1 (and a half) other ways you could write it - that don't result in branching

1:

  def something(args) do
    with {:ok, obj1} <- depencency1.call(args),
         {:ok, obj2} <- dependency2.call(obj1),
         {:ok, obj3} <- dependency2.call(obj2),
         {:ok, obj4} <- dependency2.call(obj3),
         {:ok, obj5} <- dependency2.call(obj4)
    do
      {:ok, obj5}
    else
      {:error, msg} -> {:error, msg}
    end
  end

1.5: Use a try/rescue block where you match {:ok, obj} and then catch Match errors.

I think your parent was writing Ruby, not Elixir. (Unless this is Ruby's new pattern-matching syntax that I'm not familiar with.)

Indeed if you look at my ruby code, it tries to be a with statement ;)

The parent is referring to rubocop, so I think they're talking about Ruby.

The Elixir formatter sounds much less strict, and I have very little problem with it.

mix format doesn’t have complexity rules. It will never change the semantics, it’s just there to make sure all the braces, brackets, commas, pipes, etc. end up in the same place so that it’s easy to scan a file.

mix format is not a linter it’s a formatter.

Indeed, that's why it's acceptable.

Even in that case, sometimes it breaks organization for some code that if kept as is would be more scannable to a human.

Are your objections to Rubocop's dictates in tests only (or primarily) about the complexity rules?

The complexity rules have always struck me as being of a whole different category thnan Rubocop's other rules. As you note, they're especially frustrating in tests.

Edit: by "the complexity rules" I mean https://www.rubydoc.info/gems/rubocop/0.27.0/RuboCop/Cop/Met..., rather than the ones about variable naming, line length, etc.

My problem with Rubocop is both in tests and in normal code. The rules about complexity hit both tests and production code, while the rules about tests obviously impact only that (experience limited to RSpec).

A senior developer won't need Rubocop, it's a blocker rather than an improvement. In the rare occurrence where you have an undisciplined senior developer, it's worth exploring training or re-evaluating the standards in place.

All in all, I keep thinking this is a problem of culture, if it's addressed there the value in Rubocop decreases drammatically.

That being said, Elixir formatter is "ok-ish". I didn't have the same problem with it because it doesn't overstep the boundaries of styling. It did remove valuable structure of the code for the sake of formatting standardization, so again it's actually doing damage, but at least it doesn't force you to write code that is more cryptic to a human for the purpose of pleasing a machine.

I agree Rubocop is heavy handed in the rules it hands down by default, its really useful as a formatter, but we have an internal gem at work which contains a set of less strict rules around things like complexity and method length to try and get away from having to play code golf all the time to keep Rubocop happy.

It's not even just Rubocop -- I've had this exact problem with any heavy-handed auto-linter/formatter that complains loudly about complexity without being able to understand context

Exactly. I worked at a ruby shop a while ago and the rubocop lints makes you write code and test less readable than they can be.

Eh, I think there are more important things, like if you pass a variable to a remote function, it doesn't ever mutate underneath you when you try to use it later.

Agreed. I maintain a whole bunch of codebases, many of which are a few years old, and it's so much easier to dust of an Elixir project (pre-formatter) than, say, picking up on a Wordpress or Drupal project.

6 months..! Give me a few days and I'll have forgetton anything I didn't touch at least 3 times :-)