On 18/06/13 23:38, Joerg Meier wrote:
On Mon, 17 Jun 2013 14:49:38 -0400, Eric Sosman wrote:
On 6/17/2013 2:32 PM, Joerg Meier wrote:
[...]
Personally, I found your example considerably harder to read than
the one
liner, as well as harder to read than what would have been my
solution:
private boolean askYesNoquestion (String str){
if(str.equals("yes"))
return true;
return false;
}
Or, for even greater clarity:
Obviously, in the case of booleans, this style is superfleous (and
especially in something this simple), but I was trying to demonstrate
the
style, not write a better askYesNoquestion method.
However, as for returning true/false instead of expressions, while this
would be possible in this extremely simple example, the moment you have
more conditions, you end up either writing something hard to read with
lots
of && and ||, or you end up with duplicate expressions, or you can go
with
returning true/false.
I don't find "return (((x && y) || a && (z || v)) && c);" to be
terribly
readable. "Exploding" that into a more verbose if/else structure often
ends
up making code a lot more maintainable than the 'every extra letter
must be
conserved' school of thinking.
Frankly, I'm surprised that even though it should be obvious that my
code
was no more supposed to be production code for a method that simple,my
"if (x) return true"
faced so much more ridicule than lipskas
"boolean var; if (x) var = true; return var",
which is basically the same only even more verbose.
but that's not what I wrote, and yes, I understand you were generalizing
What I actually wrote was
boolean response = false;
if(str.equals("yes")){
response = true;
}
return response;
let's analyze this (lack of error handling notwithstanding)
first we give a sensible name to the variable,
one that reflects it's existential imperative.
then we have our conditional expression. This is surrounded by braces,
always. If not you get something like this
if(str.equals("yes"))
return true;
return false;
Look familiar?
Finally we have our single return statement.
There is more to coding defensively than simply handling Exceptions
Defensive coding is also about making code easy to read, explicit,
unambiguous down the line and not 'too clever by half' so that future
maintenance is made impossible or at least very expensive.
The above has nothing to do with defensive coding. It does