Re: Proposed coding standard updates

[Andrew Haley]

Archie Cobbs writes:
 > Dalibor Topic wrote:
 > > > I'd like to propose a couple new extensions to our Java coding
 > > > standard.
 > > > 
 > > > This comes from ZipEntry:
 > > > 
 > > >  dostime = (cal.get(cal.YEAR) - 1980 & 0x7f) << 25
 > > > 
 > > > Here, `cal' is a local variable and YEAR is a static field in
 > > > Calendar.  This is valid code, but I find it somewhat confusing; the
 > > > stuff before "." is evaluated for side effects only.  I'd rather we
 > > > not use static members with a non-static qualifier, and instead write
 > > > `Calendar.YEAR'.

I think the writer's intention was to show that the YEAR field was in
the class of the member `cal'.  I don't think you can determine with a
simple one-size-fits-all rule whether this is never an appropriate
thing to do.

 > > > 
 > > > I'd also like to get rid of unused `import' statements.

I won't argue with that.

 > I've found that this book is a good place to start when trying to
 > define a set of "accepted" coding conventions:
 > 
 >   https://jjguidelines.dev.java.net/book/html/apa.html
 > 
 > Some projects have defined their coding conventions basically
 > as a "diff" from the ones defined there.

Some of these are sensible, some of them are not.  I would hope that
patches that break the more obviously sensible ones would be caught at
patch submission time.

Some things are almost an admission of bad language design:

"The synchronized modifier on methods can sometimes cause confusion
during maintenance as well as during debugging. This rule therefore
recommends using synchronized statements as replacements instead."

Andrew.