Style Guide - Revision history

Zji: /* geWorkbench Developer Style Guide */

2012-03-01T18:58:19Z

‎geWorkbench Developer Style Guide

2012-03-01T18:50:28Z

‎geWorkbench Developer Style Guide

2012-03-01T17:01:56Z

‎geWorkbench Code Organization Standard

2012-03-01T16:57:16Z

‎Coding Style

2012-03-01T16:54:57Z

‎geWorkbench Code Organization Standard

2012-03-01T16:53:28Z

‎geWorkbench Code Organization Standard

2012-03-01T16:52:47Z

‎Project Structure

2012-03-01T16:41:58Z

‎geWorkbench Developer Style Guide

2012-03-01T16:41:45Z

‎geWorkbench Developer Style Guide

2011-10-28T13:57:21Z

‎geWorkbench Developer Style Guide

← Older revision		Revision as of 18:58, 1 March 2012
Line 1:		Line 1:
	== geWorkbench Developer Style Guide ==		== geWorkbench Developer Style Guide ==
−	This document provides a style guide for developers of geWorkbench. The old content that has not been updated since 2005 may include something useful, so I keep them for now at the end the page, titled "Old Content".

	There are various good style guides out there on the Internet, this document is meant to focus on the issues that are more relevant to the current code base and development activity of geWorkbench. While it is not practical to enforce the style over the legacy code, new development should follow the guide line described here. Any [mailto:zji@c2b2.columbia.edu comments] are very welcome.		There are various good style guides out there on the Internet, this document is meant to focus on the issues that are more relevant to the current code base and development activity of geWorkbench. While it is not practical to enforce the style over the legacy code, new development should follow the guide line described here. Any [mailto:zji@c2b2.columbia.edu comments] are very welcome.

@@ Line 13: / Line 13: @@
 * Refer to the object by a proper interface instead of implementation class when possible.
 * Immutable class is preferred. Particularly, do NOT implement setters for your class if you are not sure why it is necessary.
 === Project Structure ===

@@ Line 30: / Line 30: @@
 === Creating a New Component ===
 A new component should be added as a new subdirectory of <tt>components</tt>. The subdirectory should be given a simple, descriptive, lower-case name. It should contain <tt>src</tt> and <tt>lib</tt> directories. Most importantly, the component must not depend on the classes or libraries of any other component, nor should another component depend on it. Also, the core geWorkbench classes should not depend on its classes or libraries.
 === Coding Standards ===
 The [http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html coding standards] outlined by Sun are observed.
 Here are some of rules that are particularly important to us:
-===== Capitalization =====
+==== Capitalization ====
 Constants must be in all-capitals, with underscores between words:
   public static final int MAXIMUM_FILES = 100;

@@ Line 36: / Line 36: @@
-=== Coding Style ===
+=== Coding Standards ===
 The [http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html coding standards] outlined by Sun are observed.
-Here are the coding standards that are particularly important to us:
+Here are some of rules that are particularly important to us:
-==== Capitalization ====
+===== Capitalization =====
 Constants must be in all-capitals, with underscores between words:
   public static final int MAXIMUM_FILES = 100;

@@ Line 27: / Line 27: @@
 Note that the components can depend on the core classes (those defined in <tt>./src</tt>) and the core libraries (those defined in <tt>./lib</tt>). However, components cannot depend on each other, and the core classes cannot depend on components.
 == geWorkbench Code Organization Standard==
@@ Line 32: / Line 35: @@
 === Old Content ===
 === Coding Style ===

@@ Line 18: / Line 18: @@
 === Old Content ===
 === Project Structure ===
-This section describes the directory structure of the project. The root directory structure contains the JBuilder and IDEA project and library files. It also contains this file, the <tt>java.policy</tt> file, and the <tt>build.xml</tt> ant build file.
+This section describes the directory structure of the project. The root directory structure contains eclipse project file, the <tt>java.policy</tt> file, the <tt>build.xml</tt> ant build file, and the following subdirectories besides other contents:
-* <tt>_all</tt> - A folder for a placeholder module required for the IDEA IDE.
+* <tt>_all</tt> - out of date stuff - to be removed.
 * <tt>components</tt> - The top-level directory for geWorkbench components.
 * <tt>data</tt> - Sample data files for the project.
 * <tt>lib</tt> - Library files for core geWorkbench.
 * <tt>src</tt> - Source code for core geWorkbench.
-Each component is in a subdirectory of the <tt>components</tt> directory. It contains an IDEA <tt>.iml</tt> module file and it's directory structure is as follows:
+Each component is in a subdirectory of the <tt>components</tt> directory. It contains an eclipse project file and its directory structure is as follows:
 * <tt>lib</tt> - Library files depended on by this component.
 * <tt>src</tt> - Source code for the component.

@@ Line 6: / Line 6: @@
 * If a local variable is adequate to serve your purpose, do not make it a member variable.
 * If a private member serves your purpose, do not make it public or default or protected.
-* If the class is intended to be extended, declare it as final - unless those require by geWorkbench framework not to be final.
+* If the class is not intended to be extended, declare it as final - unless those require by geWorkbench framework not to be final.
 * If the method parameter is intended to be read only, declare it as final.
 * Name classes, variables, and methods what they really are or really do. If you cannot name your class as a noun, something is wrong with your design; if you cannot name your method as a verb, something is wrong with your design.