harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Gray <chris.g...@kiffer.be>
Subject Re: Idiomatic Java: inverted conditions
Date Tue, 27 Oct 2009 14:43:58 GMT
On Tue, 27 Oct 2009 14:21:14 +0000, Tim Ellison <t.p.ellison@gmail.com>
wrote:
> On 27/Oct/2009 13:35, Xiao-Feng Li wrote:
>> On Tue, Oct 27, 2009 at 6:51 PM, Tim Ellison <t.p.ellison@gmail.com>
>> wrote:
>>> On 26/Oct/2009 21:57, Jesse Wilson wrote:
>>>> Continuing along with a theme, there's another C/C++ism in our Java
>>>> code
>>>> that frustrates me. Our Java code frequently inverts conditions from
>>>> their
>>>> natural language form.
>>> I'm sure we all have our own horror stories.  The ones that make me
>>> cringe are structured like this,
>>>
>>> public void foo(Object bar) {
>>>
>>>  if (bar != null) {
>>>    ...
>>>    <some long method, typically /too/ long>
>>>    ...
>>>    return result;
>>>  }
>>>
>>>  throw IllegalArgumentException();
>>>
>>> }
>>>
>>> Grrr.
>>>
>>> Tim
>>>
>> 
>> LOL. The code examples from Jesse, Alexey and Tim are all interesting.
>> When I saw those styles, I usually just assumed the authors must have
>> their strong justifications for that, since sometimes I saw the code
>> from some seasoned programmers and they refused to give an
>> explanation. :)  I might guess the original intention of the authors
>> is to help the (unwise) compiler to produce expected efficient code.
>> For example, with the code above, the author may expect the compiler
>> be silly and instruct it to produce fall-through code for the
>> most-frequently-taken branch. Well, with modern
>> microprocessor/compiler, this kind of code is (almost) no longer
>> needed.
> 
> I agree Xiao-Feng, and that is a poor reason to write code in this style
> anyway.  I would even suggest that coding for the compiler and coding
> for the next person who has to read the code are usually complimentary,
> such as marking fields as final, and using the most restrictive possible
> method scope, etc.  Of course, these details are usually swamped by
> higher-level algorithm choice anyway.

Some of these are indeed C-isms - e.g. "if (constant == variable)" because
if you mistakenly typed "if (constant = variable)" the C compiler would
give you an error whereas with "if (variable = constant)" it would not. (In
fact gcc will issue a warning for this pattern, so even this is moot). But
others are based on well-intentioned rules such as "conditionals should be
positive, i.e. if the conition is true this should indicate that everything
is OK", or "show the normal path of excution first and the abnormal paths
afterward". These rules sound fine until you try to put them into practice.

As for the "one return point at the end" rule, I personally don't see a
big difference between
  if (bar == null) return null;
and
  if (bar == null) throw new IllegalArgumentException();
So for me early reaturns are OK in this kind of context, especially it
there is enough whitespace around that they are not likely to be
overlooked.

Greets

Chris Gray

-- 
Chris Gray      /k/ Embedded Java Solutions

Mime
View raw message