> I don't use Ruby but I faced similar issues with Rust's clippy and rustfmt. But I still think it's better than the alternative.
I also use Go, and haven't had issues with the autoformatter there, but I believe that's mostly because there is little to no room for ambiguity around intent. You tell the compiler you want to return a Bool, and if you don't it's a compile time error. There's no "I dunno, maybe nil was an intended return value".
> Every time I'm tempted to override one of these links/formats because I feel like my way is better I like to remind myself that it's going to set a precedent for the other devs on the project
I think this misses the point somewhat. This isn't about changing the defaults of Rubocop, it's about not having some of those defaults in the first place for the places in Ruby where it's possible to express intent in a way that it's not possible to check with a linter.
> That's the thing though: consistency is somewhat objective (and enforceable), readability and maintainability not so much.
I'm still not saying that people should not use linters, just because you can lint something doesn't mean you have to lint everything.
> TFA is a good example of this: they argue that explicitly returning "nil" is more readable and better communicates intent but I suspect (once again, not being a Ruby coder myself) that other experienced Rubyists could respond that everybody knows that a method finishing without an explicit value ends up returning nil, and that adding explicit code to do is is just clutter and distracts from the important things.
Oh, absolutely, most Ruby programmers do know this, but it's not really about the code specifically I think, it's about the contract. Take this code:
def foo
@some_instance_var = 123
end
It turns out that:
> a = foo
=> 123
> a
=> 123
but you've not actually said that the return value is intended, or a side effect. You've not telegraphed the intent to the consumer of this tiny little API. It looks like returning a is merely something that happens to happen. this leads to uncertainty, guessing and possibly bugs. Take this addition later on:
def foo
@some_instance_var = 123
@some_other_instance_var = 456
end
If someone was (perhapy mistakenly) relying in the return value of foo to be the result of the assignment to @some_instance_var they now likely have a bug. Hopefully tests caught it, but they might not have.
We could fix this with (amongst other things):
def foo
return @some_instance_var = 123
end
We now know two things.
1. If we are changing this method we need to respect the return
2. If we are consuming this method we know the return is deliberate
This unfortunately violates Rubocop's redundant return detection and will be rejected (as will other forms).
> It looks like returning a is merely something that happens to happen.
This is...an odd view to me. With the exception of the "?" convention for usable-as-boolean query methods (which might not be actual booleans but you shouldn't rely on anything other than the boolean sense of the return value) and methods which are specifically documented otherwise, in Ruby every return value is and should be treated as intentional, not something that "happens to happen", and explicit return is used to avoid convoluted control structures when no better way to do so exists.
> Take this code:
> [...]
> It turns out that:
> [...]
> but you've not actually said that the return value is intended, or a side effect.
Aren't the Ruby semantics clear about what happens in both of these cases (return values of methods and assignments) and hence it was the coder's choice to leave that as the return value?
Wether the programmer chose to do something is a large part of the issue here.
An explicit return says "I chose to do this". An implicit return in these examples says "There may or may not have been a choice made" and that's the problem. If you rely on the assumption that a choice was made, you add risk.
I also use Go, and haven't had issues with the autoformatter there, but I believe that's mostly because there is little to no room for ambiguity around intent. You tell the compiler you want to return a Bool, and if you don't it's a compile time error. There's no "I dunno, maybe nil was an intended return value".
> Every time I'm tempted to override one of these links/formats because I feel like my way is better I like to remind myself that it's going to set a precedent for the other devs on the project
I think this misses the point somewhat. This isn't about changing the defaults of Rubocop, it's about not having some of those defaults in the first place for the places in Ruby where it's possible to express intent in a way that it's not possible to check with a linter.
> That's the thing though: consistency is somewhat objective (and enforceable), readability and maintainability not so much.
I'm still not saying that people should not use linters, just because you can lint something doesn't mean you have to lint everything.
> TFA is a good example of this: they argue that explicitly returning "nil" is more readable and better communicates intent but I suspect (once again, not being a Ruby coder myself) that other experienced Rubyists could respond that everybody knows that a method finishing without an explicit value ends up returning nil, and that adding explicit code to do is is just clutter and distracts from the important things.
Oh, absolutely, most Ruby programmers do know this, but it's not really about the code specifically I think, it's about the contract. Take this code:
It turns out that: but you've not actually said that the return value is intended, or a side effect. You've not telegraphed the intent to the consumer of this tiny little API. It looks like returning a is merely something that happens to happen. this leads to uncertainty, guessing and possibly bugs. Take this addition later on: If someone was (perhapy mistakenly) relying in the return value of foo to be the result of the assignment to @some_instance_var they now likely have a bug. Hopefully tests caught it, but they might not have.We could fix this with (amongst other things):
We now know two things.1. If we are changing this method we need to respect the return
2. If we are consuming this method we know the return is deliberate
This unfortunately violates Rubocop's redundant return detection and will be rejected (as will other forms).