"removing a whole line and more braces" - this is really fighting the wrong enemy. Code should be written in a way it is more readable, not shorter.
I don’t agree with him about removing the braces, though. That way madness lies.
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
... other checks ...
fail:
... buffer frees (cleanups) ...
return err;
Yes, in the presence of teardown code at the end of the method, as is common idiom in C, avoid early return. This appears to be the case for apple's "goto fail" code.
However, don't generalise this to all languages.
Only by doing multiple things in one function you really need to use goto's in C. (again, as far I can judge coding in C, not an expert!)
No, it doesn't play well with early return, so avoid mixing them.
def foo arg
return true if arg == 42
puts "got past the guard"
raise "blah"
ensure
puts "ensure always"
end
foo(42)
foo(3)
All make the "goto manual cleanup at end" less necessary, and make early return easier to use.
Personally I think sometimes shorter code, that gets rid of unnecessary bureaucracy, is more readable. For example, C++ recently (in the past decade...) gained range based iteration.
Previously:
for(containe_type::iterator i = my_container.begin(); i != my_container.end(); i++){ do_stuff(i); }
Now:
for(auto& i : my_container) { do_stuff(i); }
This is really context sensitive. Some code benefits from verbosity while other don't.
I often find inelegant, yet straightforward solutions are generally better options than dense, mathematically pure solutions, simply because inelegant code usually relies on fewer assumptions. Noting that code rarely/never evolves the way we expect it to, apply Occam's razor and strike a balance.
Readability is about clarity of intent and function, as well as sensible structure. Sometimes that means writing slightly more code with more expressive naming so that the code is easier to follow. Sometimes that means using a given language's shortcuts to condense things down.