Differences between revisions 1 and 20 (spanning 19 versions)
Revision 1 as of 2005-02-11 02:10:20
Size: 1403
Comment:
Revision 20 as of 2018-03-31 19:06:54
Size: 3178
Editor: JeffAllen
Comment: Fix Sun coding standard link
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
== Coding Standards for Java Code in Jython ==
When in doubt follow the Sun Java standards:
When contributing code or patches to Jython, please try to follow these guidelines.
Line 4: Line 3:
http://java.sun.com/docs/codeconv/ == Python Code ==
In general, follow [[http://www.python.org/dev/peps/pep-0008/|PEP 8]]. When importing Java code, always use fully qualified class names, not package names ie from java.lang import String instead of from java import lang.
Line 6: Line 6:
=== Example === == Java Code ==
 * Javadoc on any publicly exposed method or field.
 * 4 spaces for indentation, no tabs.
 * No nested ternary statements (no ternary statments inside other ternarys).
 * A luxurious 100 characters per line.
 * No copy and pasted, repeated code: if you're doing the same thing twice, make a method.
 * Braces on all loops and if else statements
 * A space between an if and its parenthesis i.e. `if (` instead of `if(`.
 * Spaces between annotation element-value pairs. i.e. `@ExposedType(name = "unicode", base = PyBaseString.class)` instead of `@ExposedType(name="unicode",base=PyBaseString.class)`
 * Methods longer than 10 lines should have whitespace and comments breaking them up into coherent operations.
 * Descriptive names for fields and methods.
 * [[http://producingoss.com/en/managing-volunteers.html#territoriality|No @author tags in code.]]
 * Any field on an object that isn't modified after construction should be final.
 * Fields at the top of the class.
 * Don't declare fields with their default values ie `private Object blah;` instead of `private Object blah = null;` and `int i;` instead of `int i = 0;`
 * Comments begin with a space unless they're commented out code:
Line 8: Line 23:
   Wrong:
   //XXX: Foo needs refactoring
   // bar.bar()
   Correct:
   // XXX: Quux is flakey
   //Baz baz = new Baz()
}}}
Beyond these rules, follow the [[http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html|Sun Java standards]].
Line 9: Line 32:
[[attachment:Eclipse_Formatting.xml]] can be imported into Eclipse to get it to follow the standards.

=== Example (adapted from Sun document) ===
{{{
Line 10: Line 37:
Line 12: Line 38:
Line 15: Line 40:
 * @author Firstname Lastname
Line 19: Line 43:
Line 22: Line 45:

/** 
    /**
Line 28: Line 50:
Line 31: Line 52:
Line 34: Line 54:
Line 37: Line 56:

/** 
    /**
Line 44: Line 62:
Line 49: Line 66:
        // ...implementation goes here...          // ...implementation goes here...
Line 51: Line 68:
Line 57: Line 73:
        // ...implementation goes here...          // ...implementation goes here...
Line 60: Line 76:
}}}  }}}

When contributing code or patches to Jython, please try to follow these guidelines.

Python Code

In general, follow PEP 8. When importing Java code, always use fully qualified class names, not package names ie from java.lang import String instead of from java import lang.

Java Code

  • Javadoc on any publicly exposed method or field.
  • 4 spaces for indentation, no tabs.
  • No nested ternary statements (no ternary statments inside other ternarys).
  • A luxurious 100 characters per line.
  • No copy and pasted, repeated code: if you're doing the same thing twice, make a method.
  • Braces on all loops and if else statements
  • A space between an if and its parenthesis i.e. if ( instead of if(.

  • Spaces between annotation element-value pairs. i.e. @ExposedType(name = "unicode", base = PyBaseString.class) instead of @ExposedType(name="unicode",base=PyBaseString.class)

  • Methods longer than 10 lines should have whitespace and comments breaking them up into coherent operations.
  • Descriptive names for fields and methods.
  • No @author tags in code.

  • Any field on an object that isn't modified after construction should be final.
  • Fields at the top of the class.
  • Don't declare fields with their default values ie private Object blah; instead of private Object blah = null; and int i; instead of int i = 0;

  • Comments begin with a space unless they're commented out code:

   Wrong:
   //XXX: Foo needs refactoring
   // bar.bar()
   Correct:
   // XXX: Quux is flakey
   //Baz baz = new Baz()

Beyond these rules, follow the Sun Java standards.

Eclipse_Formatting.xml can be imported into Eclipse to get it to follow the standards.

Example (adapted from Sun document)

package org.jython.blah;
import org.jython.blah.BlahBlah;
/**
 * Class description goes here.
 */
public class Blah extends SomeClass {
    /* A class implementation comment can go here. */
    /** classVar1 documentation comment */
    public static int classVar1;
    /**
     * classVar2 documentation comment that happens to be
     * more than one line long
     */
    private static Object classVar2;
    /** instanceVar1 documentation comment */
    public Object instanceVar1;
    /** instanceVar2 documentation comment */
    protected int instanceVar2;
    /** instanceVar3 documentation comment */
    private Object[] instanceVar3;
    /**
     * ...constructor Blah documentation comment...
     */
    public Blah() {
        // ...implementation goes here...
    }
    /**
     * ...method doSomething documentation comment...
     */
    public void doSomething() {
        // ...implementation goes here...
    }
    /**
     * ...method doSomethingElse documentation comment...
     * @param someParam description
     */
    public void doSomethingElse(Object someParam) {
        // ...implementation goes here...
    }
}

CodingStandards (last edited 2018-03-31 19:06:54 by JeffAllen)