[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch: FYI: more standards updates
From: |
Eric Blake |
Subject: |
Re: Patch: FYI: more standards updates |
Date: |
Sat, 10 Jan 2004 11:43:38 -0700 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 |
Tom Tromey wrote:
from Tom Tromey <address@hidden>
* doc/hacking.texinfo (Programming Standards): Added some more
standards.
address@hidden
+Don't use redundant modifiers. For instance, all members of an
+interface are implicitly @code{public}, so there is no need to
+explicitly declare them as @code{public}.
I think this paragraph should go further, and show all the redundant modifiers
we avoid. At least these commented modifiers are redundant:
/*abstract*/ interface I {
/*public abstract*/ void m();
/*public static final*/ int i = 1;
/*public static*/ class Inner {}
}
final class C {
/*final*/ void m() {}
}
Jikes will warn for this, with the +Predundant-modifiers command-line option.
Do we additionally want modifiers to be listed in the order recommended by the
JLS? For example, 'public static' is preferred over 'static public'. Jikes
has the +Pmodifier-order option for this.
+
address@hidden
+Because the output of different compilers differs, we have
+standardized on explicitly specifying @code{serialVersionUID} in
address@hidden classes in Classpath.
Remember also that a class may be Serializable without explicitly listing it
as a super-interface (for example, all subclasses of Throwable need
serialVersionUID).
This field should be
+declared as @code{private static final}.
address@hidden fixme index
address@hidden fixme link to the discussion
+
address@hidden
+Don't declare unchecked exceptions in the @code{throws} clause of a
+method. However, if throwing an unchecked exception is part of the
+method's API, you should mention it in the Javadoc.
+
@end itemize
Other ideas: Do we have a preferred order for declarations? For example, some
classes list fields, constructors, methods, then nested classes; and either
sort alphabetically or follow the order they are documented in Sun's API
documentation.
When overriding Object.equals, remember that 'if (!(o instanceof Foo))'
filters out null, so an explicit null check is not needed.
--
Someday, I might put a cute statement here.
Eric Blake address@hidden