Let's Talk About Conditional Expressions
You know what bugs me? People who don't write idiomatic conditionals in Ruby.
Many folks, especially those who came out of Java, .NET, or C/C++, use and abuse the ternary. The ternary is a humble little production rule that works like so:
<boolean expression> ? <eval this expression if truthy> : <eval if falsey>
The ternary can be useful if the truthy and falsey cases are terse and well-named. However, it's not uncommon to see multi-line ternaries or, even worse, nested ternaries. For example:
<script src="https://gist.github.com/1448377.js?file=delegation_1.rb"></script>By the way, the above example comes out of Rails.
Accepting that the above is just painful, how could we make it hurt less? Specifically, let's focus on the nested ternary on Line 14 (accepting that there are other ways that the code can be made clearer).
For starters, let's DRY up these Hash lookups:
<script src="https://gist.github.com/1448397.js?file=delegation_2.rb"></script>Now let's unravel this into more idiomatic Ruby. We'll extract the outer ternary into a functional style if-else. Remember that every expression in Ruby returns the value of its last executed expression. The if-else returns either the value of the computed String in the if or the empty String else. It has the advantage of containing more English words and fewer characters that resemble modem line noise or PERL.
<script src="https://gist.github.com/1448450.js?file=delegation_3.rb"></script>We can get rid of this else. After all, it doesn't contain any logic. Let's just make it the default value for method_prefix and then assign a new value only when prefix is truthy.
<script src="https://gist.github.com/1448492.js?file=delegation_4.rb"></script>Ah so what this code really cares about, first and foremost, is whether prefix is falsey. When it's falsey, it just returns an empty String! Otherwise, if it's not, it generates a String possibly using the value of prefix if and only if prefix is not true -- not a boolean.
So why should we try to avoid ternaries? Because, when used within a complex expression, they tend to lack the clarity of intent of an if-else. The lack of clarity likely resulted in the less DRY previous implementation. Once we introduced more clarity, it became obvious how this code could be DRY'd up, resulting in better readability.