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. _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
