<snip/>

> >>     if ((bp = getNextBreakPoss(childLC, null)) != null) {
> > Probably comes from long years of writing C and C++ and avoiding extra 
> > lines of code. Must be taste since I don't find it that bad, but if we 
> > all vote it out in the style rules, I'll agree to banish it!
> 
> It comes from reading code: first recognize the
> control flow, which is fortunately easy now, then
> get the assignments. Assignments buried in other
> expressions make this harder.
> As for:
>         while ((curLM = getChildLM()) != null) {
> well, this avoids writing the assignment twice.
> Nevertheless, if it's an iteration, why not use
> a more iterator like pattern:
>         while (hasNextLM()) {
>             curLM = nextLM();
> (Unfortunately, the sample code before this represents
> *not* a proper iterator pattern, which I actually find
> quite misleading).

There are exceptions for most rules and I think that Karen's example
shows where applying the exceptional case is clearer. The point is to be
able to recognize when the exceptions occur and apply them when they
increase the clarity of the code. Remember the point of these sorts of
standards is that: to increase the clarity of the code. 

<snip/>
 
>  From my experience, rules demanding to encode the scope
> of a variable in it's name are doomed for the same reason
> hungarian notation is:
> 1. You will have enough people hacking around in the code
>     who don't like it or don't care or simply feel in a
>     hurry.
> 2. It happens that a variable is moved from one scope to
>     another. You can bet that if the variable is referenced
>     more than twice, it wont be renamed. While this is
>     certainly much rarer than people generally assume,
>     it is probably the reason *why* people don't like
>     rules for encoding scope or type in names. It feels
>     like a severe restriction.

Yes but tools like checkstyle elevate some of this by warning people of
the inconsistencies.

Part of the aim of any open source project should be to make the code as
accessible as possible to potential users and contributors. One of the
key aspects to that is trying to keep the code presentation consistent
and clear.

checkstyle and the ilk make monitoring consistency trivial and the
arguments that consistency wont be achieved because someone wont do it
less effective.

IMHO (and I've benn told it doesn't always come over as humble :)),
consistent code standards are as important to the long term success of a
project as unit tests. 

-k.
 
-- 
If you don't test then your code is only a collection of bugs which 
apparently behave like a working program. 

Website: http://radio.weblogs.com/0111457/


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to