From: William G. <ww...@ts...> - 2000-12-16 18:57:58
|
This is probably not complete, but let's get started deciding on this. Note: 1) almost all of this is open for discussion. If you disagree with any of this, have additions, or have better ways of doing things, let's discuss it on the list. 2) the initial code that I wrote doesn't necessarily follow all of these rules, since I was writing it as a "one-off" app that I didn't think would ever be used by anyone else. Bad assumption on my part ;-) Part of re-architecting the code will be to modify it to conform to the final coding standards we agree on. ---------------------------------------- Naming * Class Names - proper case example: " public class TestDbConnection " * Method Names - lower case first portion, then uppercase the beginnings of subsequent words example: " public String getDatabaseName " * Variable Names - same format as method names, except for member variables, covered next. * Member Variable Names - prefixed with "m_" example: " private String m_dbName " Braces & Indentation * Braces on the line following the declaration, and indented to the same spot * Indent each new nesting level 4 spaces * Convert tabs to spaces (I think most editors can be set to do this) Exception handling * Prefer to throw exceptions up to the top level, i.e., the presentation layer. Core code should basically be an api, and should not handle exceptions itself. There may be cases where the core code does need to handle exceptions, and this should be decided on a case-by-case basis. OO and Coding Philosophy * Define interfaces for our classes. Bind on these interfaces, rather than on the concrete classes * Challenge the existence of non-static member vars: are they only used in one method? If so, they should probably be loval variables declared in that method. * There should be accessor (get / set) methods for any member vars that require visibility outside the class itself. * Try to keep method size down: if a method starts getting large and convoluted, see if there are parts that stand alone, and can be extracted to other methods. * Prefer composition to inheritance: use the basic tests to determine which to use: "is a" vs. "has a", etc. * Javadoc your code, at the method and class level. Use appropriate comments throughout the code, without belaboring the obvious, i.e., you don't need to do something like this: //load the value of the first column in the ResultSet into a temp string String tmp = rs.getString(1); However, if there's some compelling reason that might not be obvious why you're performing the operation, comment that. |