On Dec 26, 2007 4:30 PM, Charlie Groves <charlie.groves@...> wrote:
> I have a couple minor code style nits to pick with this commit... Now
> the fact that I'm raising these nits doesn't actually mean you should
> do anything about them. We don't actually have a standard way of
> doing things in Jython, and everyone else may disagree with me. I
> figured it was a good idea to get them out in the open though so we
> can come together on them a bit.
Since I'm on a formatting kick, I went ahead and updated
http://wiki.python.org/jython/CodingStandards to have some actual
guidance. Since it's such a short page, I'm pasting it all below.
I've only codified the way I've been writing things, and what I've
been enforcing in patches.
The one oddball thing is something I've just started doing recently:
100 characters per line for Java code. With the verbosity of a line
with a couple casts on it, the extra 20 characters can really make
things more compact and readable. Since almost everyone uses an IDE
or something other than an 80 column term to edit Java these days, I
don't think it's too crazy.
== 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
== Java Code ==
* Javadoc on any publicly exposed method or field.
* 4 spaces for indentation, no tabs.
* No nested ternary statements.
* 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.
* Method longer than 10 lines should have whitespace and comments
describing each of the sections, though perhaps they should be broken
up into submethods instead.
* 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.
Beyond these rules, follow the [http://java.sun.com/docs/codeconv/ Sun