<br><br><div class="gmail_quote">On 3 August 2011 12:46, Graham Ashton <span dir="ltr"><<a href="mailto:graham@effectif.com">graham@effectif.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 3 Aug 2011, at 12:28, Jordi Noguera Leon wrote:<br>
<br>
> I'd rather use:<br>
><br>
> def some_other_method<br>
>   return foo.whatever if foo<br>
>   return bar.whatever if bar<br>
>   "some message"<br>
> end<br>
<br>
</div>I don't want to pick on this specifically Jordi, but it raises an interesting issue.<br>
<br>
I like to replace methods like that with a sequence of if/elsif/else. Putting the conditional statements at the beginning makes the conditional logic clearer, and doesn't require the reader's familiarity with a more esoteric idiom.<br>

<br>
I did this very refactoring just yesterday and found a bug while I was doing it. The bug hadn't been visible when the code after "if" was off to the right of the screen.<br>
<br>
Tom Christiansen wrote about an interesting approach to the relative merits of "foo if bar" versus "foo && bar" in the Camel book (Programming Perl). To paraphrase, he argued that you should put the most significant part of the statement first, where "significant" means it'll help your understanding of what the code is doing. As I interpret it, "if foo" is more important than "return foo.whatever" in the example above (in which control flow is of primary importance).<br>

<br>
Hopefully this is making sense...<br>
<br>
It might just be me, but it seems as though the Ruby community seems to choose idioms that optimise for fewer lines of code, rather than for clarity and ease of comprehension (the two are not the same).<br></blockquote><div>
<br></div><div>I tend to prefer "return x if y" type conditions as guard clauses at the start of the method.  If the method truly was the example that Jordi suggested, then yes, a clearer if/elsif/else/end structure makes more sense, but if the "some_message" bit is actually several lines of code, then I think the 2 guard clauses are clearer.  They say to me "get outta here ASAP under these exceptional conditions" then the meat of the method is the default case.</div>
<div><br></div><div>In Simon's example, I probably would stick with if/elsif/elsif/..../end rather than guard clauses, as the method is *all* guard clause really.  That said, now I've seen this expression-less case I might be tempted to use it although it does seem like an unusual form that is likely to trip up people unfamiliar with it (which seems to be most folk on this list!)</div>
<div><br></div><div>However, I might be convinced to change page_description to take an argument and then use a traditional case along the lines of:</div><div><br></div><div>def page_description(for_object)</div><div>  case for_object</div>
<div>  when Question then for_object.background</div><div>  when User</div><div>    if for_object.bio.present?</div><div>       for_object.bio</div><div>    elsif for_object.sports.present?</div><div>       for_object.sports_list</div>
<div>    elsif !for_object.new_record?</div><div>       "Tribesports user: #{for_object.short_name}"</div><div>    end</div><div>  [SNIP OTHER CONDITIONS]</div><div>  when nil</div><div>    raise "LOL, WTF, ZOMG!!!!1111"</div>
<div>  end</div><div>end</div><div><br></div><div>Although this is arguably harder to parse, so maybe not.</div><div><br></div><div>Muz</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div></div><div class="h5">_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</div></div></blockquote></div><br>