Author: marrs
Date: Wed Feb 8 23:43:11 2012
New Revision: 1242178
URL: http://svn.apache.org/viewvc?rev=1242178&view=rev
Log:
More formatting fixes and cleanup
Modified:
ace/site/trunk/content/dev-doc/coding-standards.mdtext
Modified: ace/site/trunk/content/dev-doc/coding-standards.mdtext
URL:
http://svn.apache.org/viewvc/ace/site/trunk/content/dev-doc/coding-standards.mdtext?rev=1242178&r1=1242177&r2=1242178&view=diff
==============================================================================
--- ace/site/trunk/content/dev-doc/coding-standards.mdtext (original)
+++ ace/site/trunk/content/dev-doc/coding-standards.mdtext Wed Feb 8 23:43:11
2012
@@ -1,9 +1,6 @@
Title: Coding Standards
-Introduction
-------------
-
-This is a Java coding style guide for the project.
+This is a Java coding style guide for the Apache ACE project.
Summary
-------
@@ -68,14 +65,15 @@ The following comment block is an exampl
The following table describes the parts of a class, interface, enum or
annotation declaration, in the order that they should appear.
-|| Part of declaration || Notes ||
-|documentation|According to comment block as shown above.|
-|class, interface, enum or annotation statement| |
-|(static) variables|These should be grouped by functionality rather than by
scope.|
-|instance variables|These should be grouped by functionality rather than by
scope.|
-|constructors|Start with the default constructor if any.|
-|methods|These methods should also be grouped by functionality rather than by
scope or accessibility. E.g. a private class method can be in between two
public instance methods. The goal is to make reading and understanding the code
easier. When implementing an interface, group the methods that are part of the
interface.|
-|inner classes|Are placed at the bottom of the file.|
+Part of declaration | Notes
+------------------- | ----------------
+documentation | According to comment block as shown above.
+class, interface, enum or annotation statement |
+(static) variables | These should be grouped by functionality rather than by
scope.
+instance variables | These should be grouped by functionality rather than by
scope.
+constructors | Start with the default constructor if any.
+methods | These methods should also be grouped by functionality
rather than by scope or accessibility. E.g. a private class method can be in
between two public instance methods. The goal is to make reading and
understanding the code easier. When implementing an interface, group the
methods that are part of the interface.
+inner classes | Are placed at the bottom of the file.
##### Annotations
@@ -403,19 +401,19 @@ Blank spaces should be used in the follo
Naming conventions make programs more understandable by making them easier to
read. They can also give information about the function of the identifier.
-Identifier Type | Rules for Naming | Examples
---------------- | ---------------- | ------------
+Identifier Type | Rules for Naming |
Examples
+-------------------------------------------------- | ---------------- |
------------
(inner) classes, interfaces, enums and annotations | Names should be nouns, in
mixed case with the first letter of each word capitalised. Try to keep your
names simple and descriptive. Use whole words and avoid acronyms and
abbreviations. | class Raster;\\class TreeFrame;
-interfaces | Like class names, but if there is a name clash, the interface
wins. | Repository
-services | Same as interfaces, so don't append "Service" as you usually do not
know if an interface is a service or not. | -
-implementation classes | If a class implements an interface, it should use the
name of the interface as part of its name, adding something specific for this
implementation to it, or Impl if that does not make sense. | class
FileBasedRepository implements Repository; \\class VersionServlet implements
HttpServlet;
-exceptions | Like class names; always ending in "Exception" | InputException
-methods | Methods should be verbs in mixed case with the first letter
lowercase. Within each method name capital letters separate words. Property
methods or get-set methods are used as follows:
+interfaces | Like class names, but if
there is a name clash, the interface wins. | Repository
+services | Same as interfaces, so
don't append "Service" as you usually do not know if an interface is a service
or not. | -
+implementation classes | If a class implements an
interface, it should use the name of the interface as part of its name, adding
something specific for this implementation to it, or Impl if that does not make
sense. | class FileBasedRepository implements Repository; \\class
VersionServlet implements HttpServlet;
+exceptions | Like class names; always
ending in "Exception" | InputException
+methods | Methods should be verbs
in mixed case with the first letter lowercase. Within each method name capital
letters separate words. Property methods or get-set methods are used as follows:
When a method is used to get a value start the method name with 'get'. When a
method is used to set a value start the method name with 'set'. | run();
\\runFast(); \\setBackground();
variables (except for (constant) static final variables and member variables)
| All variables are in mixed case with a lowercase first letter. Words are
separated by capital letters. | int index;\\float myWidth;
-member variables | The same capitalisation as for normal variables prefixed
with 'm_'.|int m_index;\\float m_myWidth;|
+member variables | The same capitalisation
as for normal variables prefixed with 'm_'.|int m_index;\\float m_myWidth;|
constant (static final) variables, enum names|Names should be all uppercase
with words separated by underscores ("_"). | public static final int BLACK = 99;
-packages | Lowercase only; avoid lengthy package names; always start with
org.apache.ace. | org.apache.ace.demo.bundle
+packages | Lowercase only; avoid
lengthy package names; always start with org.apache.ace. |
org.apache.ace.demo.bundle
Downloads
---------
@@ -428,8 +426,13 @@ References
----------
- Java Code Conventions - Sun Microsystems, Inc.
+
http://java.sun.com/docs/codeconv/
+
- How to Write Doc Comments for JavaDoc - Sun Microsystems, Inc.
+
http://java.sun.com/j2se/javadoc/writingdoccomments/
+
- JavaDoc homepage - Sun Microsystems, Inc.
+
http://java.sun.com/j2se/javadoc/
