Style discussion, Oct 09 edition

[Sean Owen <sr...@gmail.com>]

May I suggest we don't static import classes unless it makes a real
difference in readability, but certainly, may I suggest we don't
static-import a single static method or field from a class? finding a
reference to it in the code becomes confusing because one expects the
method or field exists in the class itself, since it is unqualified.

I see a number of classes under .df.* that implement equals() but not hashCode()

As a matter of practice, better to not allocate a zero-length array.
Since one is the same as the next, makes sense to declare one as a
static field and reuse it. But certainly it can be entirely elided in
phrases like this:
URI[] files = new URI[0];
files = ...;
The allocation is completely superfluous.

This doesn't make sense when the args are ints:
Math.floor(numTrees / numMaps)
The result is already an int, rounded 'down'

StringBuffer has basically been replaced with StringBuilder since Java 5

No method should be declared 'throws Exception' except for special
cases like main()

An abstract class which defines only abstract methods should likely
just be an interface, for flexibility

C-style array declarations work in Java but are not used -- int foo[]
should be int[] foo

Standard modifier ordering in Java is like 'public static final'

In a line like this, the 'new URI[]' is redundant
URI[] foo = new URI[] { something };

Lines like 'foo = foo % 10' may be improved to 'foo %= 10'

Re: Style discussion, Oct 09 edition

[Ted Dunning <te...@gmail.com>]

Yes.  It is just expectations.

x += 1= or x++ or x-- are all common.  Other operations are uncommon and %
in particular has the deviant property of other meanings in other languages
(it is often a comment character).

On Thu, Oct 1, 2009 at 12:21 PM, Sean Owen <sr...@gmail.com> wrote:

> Is it
> merely a question of what one expects to read? I am more accustomed to
> the latter form.
>



-- 
Ted Dunning, CTO
DeepDyve

Re: Style discussion, Oct 09 edition

[Sean Owen <sr...@gmail.com>]

It's so small that I can't feel strongly about it either way. Is it
merely a question of what one expects to read? I am more accustomed to
the latter form. The language allows it and I'm used to seeing it in
various forms like "i++". It can only be faster, at runtime, since it
might avoid an additional store instruction, though I actually expect
javac takes care of it.

Any other thoughts? if not, I am not going to 'fix' this.

On Thu, Oct 1, 2009 at 5:08 PM, Ted Dunning <te...@gmail.com> wrote:
>>  Lines like 'foo = foo % 10' may be improved to 'foo %= 10'
>>
>
> Some of us don't think that this is an improvement.
>

Re: Style discussion, Oct 09 edition

[Ted Dunning <te...@gmail.com>]

On Thu, Oct 1, 2009 at 2:29 AM, Sean Owen <sr...@gmail.com> wrote:

> This doesn't make sense when the args are ints:
> Math.floor(numTrees / numMaps)
> The result is already an int, rounded 'down'
>

Since other languages have incoherent rounding rules for this division, this
idiom can actually help readability.  It certainly doesn't help performance
so it should be avoided in inner loops.

If it is "optimized" away, I would suggest a comment to make sure the reader
remembers the rounding rule in Java.


>  No method should be declared 'throws Exception' except for special
> cases like main()
>

Even then it is better to declare the specific exceptions.  With a modern
IDE, it costs zero effort to do a better job.


>  An abstract class which defines only abstract methods should likely
> just be an interface, for flexibility
>

Unless it is an external API in which case the abstract class may be more
future proof.


>  Lines like 'foo = foo % 10' may be improved to 'foo %= 10'
>

Some of us don't think that this is an improvement.



-- 
Ted Dunning, CTO
DeepDyve