Author: buildbot
Date: Wed Feb 8 23:43:22 2012
New Revision: 804292
Log:
Staging update by buildbot for ace
Modified:
websites/staging/ace/trunk/content/dev-doc/coding-standards.html
Modified: websites/staging/ace/trunk/content/dev-doc/coding-standards.html
==============================================================================
--- websites/staging/ace/trunk/content/dev-doc/coding-standards.html (original)
+++ websites/staging/ace/trunk/content/dev-doc/coding-standards.html Wed Feb 8
23:43:22 2012
@@ -151,8 +151,7 @@
<p><a href="/"><i class='icon-home'></i> Home</a> » <a
href="/dev-doc/">Dev-doc</a></p>
<h1>Coding Standards</h1>
<div class="clear"></div>
- <div id="content"><h2 id="introduction">Introduction</h2>
-<p>This is a Java coding style guide for the project.</p>
+ <div id="content"><p>This is a Java coding style guide for the Apache
ACE project.</p>
<h2 id="summary">Summary</h2>
<p>This style guide is intended to help the computer professional produce
better Java programs. It presents a set of specific guidelines for using the
features of Java in a disciplined manner. The goal is to develop high quality,
reliable, reusable, portable software. For a number of reasons, no programming
language can ensure the achievements of these desirable objectives on its own.
Programming must be embedded in a disciplined development process that
addresses a number of topics in a well managed way. The use of Java is one of
those. It must conform to good programming practice based on well established
software engineering principles. This style guide is intended to bridge the gap
between these principles and the actual practice of programming in Java.</p>
<p>Clear, readable, understandable source text eases program evolution,
adaptation and maintenance. First, such source text is more likely to be
correct and reliable. Second, effective code adaptation is a prerequisite to
code reuse, a technique that has the potential for drastic reductions in system
development costs. Easy adaptation requires thorough understanding of the
software, and that is facilitated considerably by clarity. Finally, since
maintenance (really evolution) is a costly process that continues throughout
the life of a system, clarity plays a major role in keeping maintenance costs
down. Over the entire life cycle, code has to be read and understood far more
often than it is written; the investment of effort in writing readable,
understandable code is thus well worthwhile. Many of the guidelines in this
style guide are designed to promote clarity of the source text.</p>
@@ -199,14 +198,44 @@
<p>The following table describes the parts of a class, interface, enum or
annotation declaration, in the order that they should appear.</p>
-<p>|| 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.|</p>
+<table>
+<thead>
+<tr>
+<th>Part of declaration</th>
+<th>Notes</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>documentation</td>
+<td>According to comment block as shown above.</td>
+</tr>
+<tr>
+<td>class, interface, enum or annotation statement</td>
+<td />
+</tr>
+<tr>
+<td>(static) variables</td>
+<td>These should be grouped by functionality rather than by scope.</td>
+</tr>
+<tr>
+<td>instance variables</td>
+<td>These should be grouped by functionality rather than by scope.</td>
+</tr>
+<tr>
+<td>constructors</td>
+<td>Start with the default constructor if any.</td>
+</tr>
+<tr>
+<td>methods</td>
+<td>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.</td>
+</tr>
+<tr>
+<td>inner classes</td>
+<td>Are placed at the bottom of the file.</td>
+</tr>
+</tbody>
+</table>
<h5 id="annotations">Annotations</h5>
<p>Annotations for classes and methods should be done on the line directly
above the class or method. They should be indented to the same level. An
example:</p>
<div class="codehilite"><pre><span class="nv">@Manageable</span><span
class="p">(</span><span class="n">description</span> <span class="o">=</span>
<span class="s">"Starts the system."</span><span class="p">)</span>
@@ -595,13 +624,17 @@ xCoord--;</p>
</ul>
<h2 id="references">References</h2>
<ul>
-<li>Java Code Conventions - Sun Microsystems, Inc.
- http://java.sun.com/docs/codeconv/</li>
-<li>How to Write Doc Comments for JavaDoc - Sun Microsystems, Inc.
- http://java.sun.com/j2se/javadoc/writingdoccomments/</li>
-<li>JavaDoc homepage - Sun Microsystems, Inc.
- http://java.sun.com/j2se/javadoc/</li>
-</ul></div>
+<li>Java Code Conventions - Sun Microsystems, Inc.</li>
+</ul>
+<p>http://java.sun.com/docs/codeconv/</p>
+<ul>
+<li>How to Write Doc Comments for JavaDoc - Sun Microsystems, Inc.</li>
+</ul>
+<p>http://java.sun.com/j2se/javadoc/writingdoccomments/</p>
+<ul>
+<li>JavaDoc homepage - Sun Microsystems, Inc.</li>
+</ul>
+<p>http://java.sun.com/j2se/javadoc/</p></div>
<hr>
<footer>
<p>Copyright © 2012 The Apache Software Foundation, Licensed
under the <a href="http://www.apache.org/licenses/LICENSE-2.0";>Apache License,
Version 2.0</a>.<br/>Apache and the Apache feather logo are trademarks of The
Apache Software Foundation.</p>
