The Semantic Rule for { } VS do/end

[jimweirich]

The style guide suggests using {...} for single line and do/end for multiple line blocks.

Is it worth mentioning the semantic rule for choosing {} VS do/end as another possibility? The semantic rule says use {} for blocks where the primary purpose of the block is to return a value, use do/end for blocks where the primary purpose of the block is to execute side effects.

Although a minority style choice, the semantic rule does have a significant following:

• http://devblog.avdi.org/2011/07/26/the-procedurefunction-block-convention-in-ruby/
• http://talklikeaduck.denhaven2.com/2007/10/02/ruby-blocks-do-or-brace
• http://onestepback.org/index.cgi/Tech/Ruby/BraceVsDoEnd.rdoc

[as016194]

👍

We use the semantic rule in our internal style guide and I'd like to see it used more.

[fuadsaud]

Really interesting. do...end doesn't really make sense if you're just returning something that takes more than a line, or is too big for putting the same line.

However, I feel a little awkward about do...end one liners.

[fuadsaud]

@bbatsov thoughts?

[bbatsov]

Generally I dislike semantic rules, because they cannot be enforced automatically. If the code style cannot be automatically enforced it's quite likely it will be violated. At one point I supported the semantic and/or rule, but few years down the line I'm convinced it doesn't make sense. And I find do...end on a single one extremely awkward looking, but of course - I'm biased, having used the other style since day one.

[adkron]

do...end could aways be put on multiple lines even if you have a single line statement. I like the semantic rule.

[fuadsaud]

hmm, and it could be enforced that if you're chaining a method call to the block you should be using brackets

[lee-dohm]

I agree with @bbatsov, in my experience a rule that is not automatically enforced is not truly a rule, it's more like a guideline because it will not be followed consistently.

Also, I feel like style rules should preferably be discoverable by reading well-written code. This is where most styles start, after all, adopted from large bodies of code or commonly-read books, consistently written in a single way. I don't believe that the semantic rule for blocks is sufficiently discoverable by this test. Without previous knowledge of the rule, looking at a large body of code ... would I assume that there was a pattern to the choice of {...} versus do...end? I'm not sure.

[jimweirich]

Just a couple of comments.

(1) The rule could certainly be automatically enforceable via analysis of the source of the called function. And even if the source is not available, the behavior of the method of Enumerable is well know and could be encoded into an enforcer (e.g. "each" never uses the return value, "map" always does). This would cover the majority of the block uses.

(2) Style rules that only reflect what is easily discoverable by a trivial examination of the source code seem to me to be the least valuable rules. If the style is not conveying additional information, why bother? E.g. the one VS multiline rule tells me nothing about the code that isn't already painfully obvious from the layout of the code. The semantic rule gives the reader additional information about the intent of the code. And that's what I find valuable.

Just some thoughts. Thanks.

[iGEL]

@lee-dohm Has it occurred to you that this thing is called style guide 😜 ?

Other than that, I just can agree with

(2) Style rules that only reflect what is easily discoverable by a trivial examination of the source code seem to me to be the least valuable rules. If the style is not conveying additional information, why bother? E.g. the one VS multiline rule tells me nothing about the code that isn't already painfully obvious from the layout of the code. The semantic rule gives the reader additional information about the intent of the code. And that's what I find valuable.

👍

[zenspider]

It's been a long while, but I want to pick up Jim's torch here and run with it a bit. Namely:

The rule could certainly be automatically enforceable via analysis of the source of the called function.

There's probably an easy win here that can cover a majority of the cases quite easily.

and

Style rules that only reflect what is easily discoverable by a trivial examination of the source code seem to me to be the least valuable rules.

and to push back on @bbatsov's comment:

Generally I dislike semantic rules

So, you're planning to phase out Style/SignalException and Style/NonNilCheck? They're semantic checks, right? I agree that those are easier to intuit the semantic intent, but it is just as arguable that you can do that for the Weirich method most of the time.

I think it can also be argued that those who use the Weirich method generally don't use do/end on a single line. It just doesn't really mentally fit for what a do/end block is meant for.