Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!storethat.news.telefonica.de!telefonica.de!news-1.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Robert Klemme <shortcutter@googlemail.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: About java program.
Date: Tue, 18 Jun 2013 08:24:48 +0200
Lines: 83
Message-ID: <b2acppFo11U1@mid.individual.net>
References: <324f929f-772e-4004-81e1-6b454cdae794@googlegroups.com> <b24an6FlpvpU1@mid.individual.net> <UoednTl5R618JiDMnZ2dnUVZ8iadnZ2d@bt.com> <b263siF2vkkU1@mid.individual.net> <uBDvt.60965$5i1.39234@newsfe15.iad> <ILKdnZ-vg53OjiLMnZ2dnUVZ7tmdnZ2d@bt.com> <kpo2oa$j1e$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Trace: individual.net 14AqoEiBbpCij1jnoJUfBg1TPtSubv/B4JAn1XOw6sfnepo60=
Cancel-Lock: sha1:XnouwwnNsOAAo5nidilq5cNIk+0=
User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
In-Reply-To: <kpo2oa$j1e$1@dont-email.me>
X-Antivirus: avast! (VPS 130617-2, 17.06.2013), Outbound message
X-Antivirus-Status: Clean
Xref: csiph.com comp.lang.java.programmer:24447

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=20
there are in a method the easier it is to read.  Of course, there are=20
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=20
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=20
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=20
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.=20
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=20
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

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/