Landon,
Here are my comments
1. Code formatting is very important in the FOSS world as you have
many developers modifying the code. If you have consistent
formatting then when you do a diff/merge you can see the real
changes between the code and not just the differences in
whitespace or curly brace locations. Sun has a good document
describing a set you can work from. http://java.sun.com/docs/codeconv/
2. We should also setup the use of Checkstyle (there is an eclipse
plugin), this allows you to define a number of rules such as
making all method parameters final so you don't modify the value
of the parameter when you actually meant to modify the value of
the field.
3. On the use of this, I personally don't think it should be used on
every time you use a field, just when name clashes occur or when
assigning values in a constructor. By using the final keyword for
parameters you avoid assigning to the parameter rather than the field.
4. Correct configuration of modern Java IDE's can avoid syntax based
programming conventions. For example fields in eclipse are in
italics. Also you can have it underline pointless assignments such
as foo = foo instead of this.foo = foo
5. I agree that when invoking methods you should avoid using another
method call to provide a value. In these cases assign a local
variable. Some cases such as say Arrays.asList are so simple they
could be inline. There are two reasons for this:
1. It is more readable to not have a complex statement on one
line. And more understandable as you have a descriptive name
of each parameter.
2. When using a debugger if you have it on one line you have to
step into each method call before you can step into the main
method which makes debugging a pain. Also you don't get to
see the value of those parameters before making the method call.
6. Avoid using inline conditionals x ? y : z
Paul
Sunburned Surveyor wrote:
I'm thinking about the preparation of a short document with code style
tips for Java FOSS programming.
There is the concise way to code something, and then there is the way
to code something in a manner that will
makes it more understandable for the guy that has to come behind you.
I think this is probably more important in FOSS programming than it is
in "normal" or proprietary programming.
I'm not talking about where you put the curly braces or other stuff like that.
I'm talking about things like using the "this" keyword when
appropriate, avoiding long method call chains in the argument list of
a method call, and avoiding complicated groups of statements with no
comments indicating the purpose or desired result.
I realize not everyone will agree that code should be written for
clarity at the cost of some conciseness. However, if you have some
style suggestions that I could consider and include in the sheet I
would welcome them. (I'm not looking for stuff that is in the existing
Java style books. I have those. :] I'm looking for suggestions that
deal with the type of clarity that becomes critical in open source
programming, especially when a the next maintainer or contributor
might not be a programming professional.)
The Sunburned Surveyor
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
