[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
+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.

+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
+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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]