(setq t nil)
"Most men lead lives of quiet desperation and go to the grave with the song still in them." -Henry David Thoreau
Author: Matt Stancliff (matt@cc.gatech.edu)
Creation Date: 2002/10/31
Last Updated: 2002/10/31
Here are just a few of my gripes from what I've seen... feel free to follow
them :) I believe most of the points I make are from the Java Coding Standards
Just a few points...
"Helper classes" that don't compile and have no functionality...
If you want someone to implement some functionality, tell them
via email or drop a file in the DesignDocs directory about what you
want them to do... don't try to outline files for them to flesh
out later. If a person is supposed to implement functionality, don't
try to write half to set up a guideline... just guideline it in a
text file or whatnot and let them know. :)
Reasons:
1.) CVS Clutter.
Ant compiles *everything* that is *.java in the src directory
Adding non-compiling code to the src directory is a BadThing(TM)
2.) Clarity.
Time is better spent describing to the person in a file what you
want them to implement rather than writing vague code and hoping
the other people will figure out what is supposed to be
implemented.
Vector isn't the best all the time.
(okay, so this is completely opinion, but it's true! :))
Vector does *a lot* of stuff, which makes it bloated and not necessarily
the most efficient Class for the job.
Check out (all in java.util):
LinkedList
LinkedHashSet
LinkedHashMap
WeakHashMap <-- nifty!
HashTable
ArrayList
and others too.
It's possible Vector is a good choice, but don't just throw it around
as if it is the only option for a data structure :)
Don't use javadoc comments (/** something */) for non-javadoc comments!
Just use the regular /* look, it's a comment */
Spaces, spaces, spaces!
public class Fee {
^ <-- SPACE = GOOD
int joe; // end-line comment for joe
^ <-- SPACE = GOOD
Cuddle those parameters!
public void fee(String in_string); /* A good way */
^^^ <-- NO SPACES ^^ <-- NO SPACES!
as opposed to...
public void fee( String in_string ); /* A bad way */
^^^^ <-- NOT COOL ^^^ <-- NOT COOL
The double slashie!
// int joe;
int joe; /* joe does blah blah */
^ <-- SPACE and NOT a double slashie...
reserve double slashies for commenting out LINES of CODE
Use /* */ for COMMENTS
Yeah, so the choice of // or /**/ for an endline comment
isn't a big deal, but the space issue makes things easier
to read!
Class Comments
When making a class, ALWAYS use a main class comment.
e.g.
/**
* Class Foo
*
* Class foo is used for blah blah and does fee fee and p00ps too.
*
*
* @author FirstName LastName (emailaddress)
* @version 1.9
*/
Version and a detailed description are optional, but it is *very* useful
to have the author and a basic one or two lines of info about the class.
End... so far. :)