Re: About java program.
On 18.06.2013 00:36, Joshua Cranmer =F0=9F=90=A7 wrote:
On 6/17/2013 8:46 AM, lipska the kat wrote:
... and what is your opinion of defensive coding?
The term, as I understand it, refers to coding under the assumption tha=
t
everyone who uses your API is a stupid idiot who can't follow your rule=
s
properly. The matter at hand here is basically a stylistic concern abou=
t
which is mentally easier to follow, which falls under the category of
"everyone has an opinion which is strongly held and won't be changed."
I would say though that - as a rule of thumb - the less decision points
there are in a method the easier it is to read. Of course, there are
always degenerate cases but this is certainly not one of them.
This discipline is hard to learn and once learned even harder to
un-learn. This is why I don't like things like
return str.equals("yes");
It's lazy coding and harder to understand than my example
That's not lazy. Looking through the real intent of the code and
stripping the code down to exactly the minimal readable solution is more =
work than just applying if else. For me, _that_ is lazy coding: it's
much simpler to hack something that "just works" than to think about the =
problem to solve more and come up with a more structured and more
concise solution.
To you, maybe. To me, no. This kind of one liner immediately indicates
to me that the function is equivalent with the notion that the string i=
s
exactly "yes". In your example, by contrast, that equivalence is not
obvious: it says that the answer is false unless the string is exactly
"yes", and uncovering the functional equivalence requires resolving a
double-negative.
Exactly.
if(something){
return something;
}
else if(something else){
return something else;
}
else{
return some other value
}
It is much easier to understand and debug
the following
First of all, that code above is in a method which returns a boolean.
So there are just two outcomes which can be easily handled by the return =
statement with ||. If there are more input values which yield true then =
one would rather use HashSet<String> to calculate the return value. At
least that would be the OO solution to me - and not a cascade of, say 7, =
if else.
Style wars much? To me, personally, early-return is often valuable,
especially in languages like C++ or Java which have useful constructs
for handling post-call cleanup such as RAII or try-finally blocks. I'm
going to stop short of saying I prefer early-return, since it is very
much a decision that applies in a specific context, and these examples
are all trying to apply a universally generic rule.
Same here.
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/