stand00

最新推荐文章于 2020-11-12 16:52:45 发布

乾朗

最新推荐文章于 2020-11-12 16:52:45 发布

阅读量141

点赞数

分类专栏： Java学习类

本文链接：https://blog.csdn.net/hexiaojiao/article/details/30485673

版权

Java学习类专栏收录该内容

4 篇文章 0 订阅

订阅专栏

<html>
<style>
table {
background-image: none;
background: #ffffff;
font-family: arial, helvetica, sans-serif, kanji2;
font-size: 10pt;
border : 0px;
}

.stepHeading {
background-color: #ffffff;
color: #293d6b;
font-family: arial, helvetica, sans-serif, kanji2;
font-size: 10pt;
font-weight: bold;
padding-bottom: 2px;
padding-left: 2px;
padding-top: 2px;
text-decoration: none;
border-top: 1px dotted #cccccc;
}
</style>

<body>
<div>
<div class="sectionContent">
<table class="sectionTable">
<tbody><tr>
<td class="sectionTableCell">
<div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> All code must adhere to all license restrictions  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Regardless of whether the code belongs to HSBC or a third-party supplier, always adhere to any licensing restrictions.
Remember that source code may have licences that are separate to the product/application they create, and may provide their
own (reduced or increased) restrictions of usage.  Where application of any standard would break the legal licensing
arrangement, never apply the standards without further guidance from Group Legal.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Always be consistent; never mix coding styles  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
Irrespective of other guidelines here, it's important that a single source file follows the same set of syntactic
standards.  Failure to do so, makes it extremely difficult to read and understand the code, thereby increasing the
probability of errors being introduced, and making the application harder to debug.  For Java projects these
Coding Standards must be enforced, <strong>and tooling used to reformat any applications that do not confirm</strong>
to the standards. Where reformatting of non-compliant applications is not possible (including non-Java projects) the
existing standard should be maintained.  All compilation units (Java classes) MUST adopt the same style; it's
permissible for different units (e.g. JARs) to have different styles at any given point depending on the status of the
migration and ever-greening process of legacy code.
</p><br></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#000000;font-size:larger;">
<br>File Organisation</span>
  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Always use .java filename suffix for Java source code files  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Each .java file contains ONLY the single definition of a similarly named class, together with any inner definitions of that class {java}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
In other words, for a file named <code>MyClass.java</code>, there must only be a single (outer) class named
<code>MyClass</code>. For example, the general file layout must follow that shown below with no additional outer class
or interface definitions.
</p>
<p style="MARGIN-LEFT: 50px; MARGIN-RIGHT: 50px; BACKGROUND-COLOR: rgb(240,240,240)">
<code><span style="COLOR: #009900">/*<br>
 * COPYRIGHT. HSBC HOLDINGS PLC 2005. ALL RIGHTS RESERVED.<br>
 *<br>
 * This software is only to be used for the purpose for which it has been<br>
 * provided. No part of it is to be reproduced, disassembled, transmitted,<br>
 * stored in a retrieval system nor translated in any human or computer<br>
 * language in any way or for any other purposes whatsoever without the<br>
 * prior written consent of HSBC Holdings plc.<br>
 */</span><br>
package com.hsbc.group.component.MyPackage;<br>
<br>
import java.lang.Number;<br>
import com.hsbc.group.something.OtherClass;<br>
<br>
<span style="COLOR: #009999">/**<br>
 * JavaDoc comment...<br>
 *<br>
 * @version $Revision$, $Date$<br>
 */</span><br>
public class MyClass {<br>
   ...<br>
<span style="COLOR: rgb(0,144,0)">   // class members, including attributes, methods, inner classes,
constants, etc...<br>
</span>   ...<br>
}<br>
<br>
</code>
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Avoid Java source files that are over 2000 lines {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Large source files are cumbersome to maintain, and usually indicate that an appropriate level of design and/or decompositon
has not been undertaken.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> All source files begin with a 'c-style' comment that lists the standard copyright notice {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>The following snippet shows the standard copyright header as it should appear in Java code (the year should be changed to
reflect the appropriate years over which the file was created and modified).
<p style="MARGIN-LEFT: 50px; COLOR: #008000; MARGIN-RIGHT: 50px; BACKGROUND-COLOR: #f0f0f0">
<code>/*<br>
 * COPYRIGHT. HSBC HOLDINGS PLC 2005. ALL RIGHTS RESERVED.<br>
 *<br>
 * This software is only to be used for the purpose for which it has been<br>
 * provided. No part of it is to be reproduced, disassembled, transmitted,<br>
 * stored in a retrieval system nor translated in any human or computer<br>
 * language in any way or for any other purposes whatsoever without the<br>
 * prior written consent of HSBC Holdings plc.<br>
 */</code>
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> All import statments list each module explicitly; the * wildcard is never used {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
This prevents unnecessary classes being made available, which in turn aids compilation performance and reduces the risk
of name clashes occuring.  For example:
</p>
<table title="" cellspacing="0" cellpadding="2" align="center" border="1">
<tbody>
<tr style="BACKGROUND-COLOR: #fff0f0">
<td>
<span style="FONT-WEIGHT: bold; COLOR: red">Disallowed :</span>
</td>
<td>
<p>
<code>import java.awt.*;<br>
import java.applet.*;</code>
</p>
</td>
</tr>
<tr style="BACKGROUND-COLOR: #f0fff0">
<td>
<span style="FONT-WEIGHT: bold; COLOR: #009000">Mandatory :</span>
</td>
<td>
<code>import java.awt.Frame;<br>
import java.awt.Graphics;<br>
import java.applet.AppletContext;</code>
</td>
</tr>
</tbody>
</table></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Always provide a package.html file that provides Java documentation for every Java package  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[Suggested]</span> Provide a README file within directories to summarise their contents  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#000000;font-size:larger;">
<br>Indentation and Layout</span>
  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Standard formatting must be followed; compound statements are indented by one level {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
Standard formatting include the following rules:
</p>
<ul>
<li>
No space between method names and the opening parenthesis
</li>
<li>
No space between the opening and closing parenthesis and the method parameter list
</li>
<li>
Keywords (not method names) and subsequent parenthesis are separate by a single space
</li>
<li>
The opening brace for a code block (method, condition, loop, etc.) occurs on the same line as the declaration or
statement
</li>
<li>
The closing brace for a code block appears on its own line, indented to match the opening delcaration or statement
(except for null statements)
</li>
<li>
Compound statements (statements within code blocks created by methods, conditions, loops, etc.) are
indented by one level
</li>
<li>
Opening and closing braces are always used even for compound statements, even where they would contain a
single solitary statement
</li>
<li>
Null statements are formatted with the closing brace immediately following the opening brace, that is
<code>{}</code>
</li>
<li>
Methods are separated by a single blank line
</li>
<li>
Local variables declarations and subsequent statements are separated by a blank line
</li>
<li>
Code blocks (methods, conditions, loop, etc.) are preceeded by a blank line
</li>
<li>
Single line comments are preceeded by a blank line, except where the comment relates specifically to the preceeding
code
</li>
<li>
Multiple blank lines are used to separate sections of the source file, for example where all methods change from
public into private
</li>
<li>
Opening braces are preceeded by a space
</li>
<li>
A blank space is provided after a comma operator, whether that's in a statement, parameter/argument or expression
list
</li>
<li>
Within for statements, a single space is always provided after the semi-colon
</li>
<li>
Unary operators are always joined to their operand (eg. x++)
</li>
<li>
Binary operators (exception for .) are always separated by a single space from their operands (eg. x + y)
</li>
<li>
The . operator is always joined to both operands (eg. x.y)
</li>
<li>
Cast operators are always followed by a single space, although this may be omitted where it improves readability
</li>
</ul>
<p>
The Sun Java code conventions provide examples of the formatting standard.
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> 4 spaces is always used for indentation; TAB characters are never used {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Most development environments providing tooling that automatically format the code to use spaces, and/or provide
preferences that allow whether the TAB key produces the TAB character or a defined sequence of spaces.  Where
possible, correctly configure the "format on save" tooling to correctly indent source files after modification.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Avoid long lines; never exceed 132 characters per line {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Long lines are hard to read and maintain.  Ideally keep lines under 80 characters, but where this impairs readability,
structure the code to be readable even if this exceeds 80 characters.  Line which may exceed 80 characters
include:
<ul>
<li>
Lines which contain a single assignment of a long string literal;
</li>
<li>
Lines which contain a single statement where the tokens within that statement prevent clear and unambigous wrapping
within the 80 column limit;
</li>
<li>
Nested condition groups, the meaning of which becomes unclear, when releated sub-conditions are moved onto separate
lines.
</li>
</ul>In all cases use common sense and judgement to determine whether the trade-off in respect to ongoing maintenance,
debugging and printing (caused by exceeding 80 columns) is viable and necessary to ensure the ongoing maintainability and
readability of the code. Never exceed 132 characters as this prevents the code being printed correctly.  Where code
samples are being used in documentation (including JavaDoc and paper documents) attempt to keep code examples under 70
characters, as this improves readability considerably.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Wrap lines that cannot fit within the 132 characters limit; always wrap lines to the Sun standard convention {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
All lines that exceed 132 characters (and most that exceed 80 characters) must be wrapped such that:
</p>
<ul>
<li>
line breaks occur after a comma or before an operator
</li>
<li>
there's a preference for higher-level (more abstract) breaks to lower level (nested) breaks
</li>
<li>
new lines are aligned with the beginning of the expression at the same level on the previous line
</li>
<li>
indentation of 8 spaces is used where code becomes unreadable
</li>
<li>
ternary expressions are wrapped at the <code>?</code> and <code>:</code> operators
</li>
</ul>
<p>
The Sun Java code conventions provides numerous examples that follow this standard.
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Avoid excessive nesting; limit nesting to 3 levels {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>This is one of key justifications for a 4 space indentation: when combined with the 80 column limit, it's easy to see when
nesting is getting too deep.  The general view is that there should be no more than 3 levels of nesting.  After 4
or 5 levels of nesting, code generally becomes hard to follow especially where the nesting is being created by loops or if
statements with associated else clauses.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Make loops easy to read and understand; make them short enough to view in whole  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Limit methods lengths to keep whole methods visible {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Ideally methods lengths should be limited to a maximum of one page (around 20 to 40 lines), as this allows the whole method
to be viewed, written and easily debugged without scrolling, and printed without spanning multiple pages. Also, long
methods are often a good indicator of code that can be refactored into multiple methods. Obviously what meets the
"visibility" requirement will change depending on an individual's set-up, so judgement and the results of the Checkstyle
tool (particularly in respect to the cyclomatic complexity value) should be used.   Overall, this aids
readability and helps prevents flaws being introduced as any nesting is clearly visible, together with both the statements,
conditions and exit paths implicit in that nesting.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Make complex conditions easy to read and understand; make them short enough to view in whole {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Programming defects are reduced when the whole condition is visible; debugging and subsquent maintenance is easier.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#000000;font-size:larger;">
<br>Comments</span>
  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> The Java documentation for any class (.java file) must include appropriate SCM tags to identify the class version  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
That is, to ensure that the Java documentation is easily identifable for any given version, the following SCM (MKS)
identifier tags must be included as part of the class Java documentation and identified using the @version
annotation.  For example:
</p>
<p style="MARGIN-LEFT: 50px; MARGIN-RIGHT: 50px; BACKGROUND-COLOR: #f0f0f0">
<code><span style="COLOR: #007090">/**<br>
 * JavaDoc comment...<br>
 * @version $Revision$, $Date$<br>
 */</span><br>
public class Account {<br>
  ...<br>
</code>
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Single-line, trailing and end-of-line comments always use the double-slash (//) style rather than 'c-style' {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Never use the /*...*/ format for single line or trailing comments; use the c-style notation only for block comments
including the HSBC copyright message at the start of the file.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Comments must clarify the intent of the code and not repeat the code in a more verbose manner  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>In other words, comments should aim for a higher level of abstraction and focus on the 'why' rather than the how; the code
itself shows the how and should be written such that the intent is obvious from the code itself.  This applies to both
Java documentation (<code>/**...*/</code>) and Java implementation (<code>/*...*/</code> and <code>//...</code>)
comments.  All comments should be aimed at improving the understanding of the program, with Java documentation
comments used for the "public" facing view and implementation comments used for the internal or "private" view.  Be
aware that excessive comments is usually an indication of bad code design; prefer readable code over excessive and
unnecessary comments.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Comments should use natural language to describe the purpose/intent of the code, using natural mixed-case sentences and punctuation.  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>In other words, avoid using capitals which make the comments hard to read; always be aware that JavaDoc comments will be
transcribed directly into the generated web site.  Avoid replicating code within the comments, repeating or
re-interating what the code is doing through some form of pseudo-code.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> All public, protected and package definitions (including classes, interfaces and variables) must have appropriate Java documentation {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>This Java documentation must describe the specification and intent of the code, free of implementation specific
details.  It must be written in such a manner that developers who do not have the source code to hand, may make best
use of the code; in effect it's aimed at client developers using the code (it must document the public API) as well as
those responsible for maintaining the code in the future.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Use "XXX" in comments to indicate something that's bogus but works, use "FIXME" to identify something bogus and broken, use "TODO" to identify missing code  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[Recommended]</span> All private definitions (including classes, interfaces and variables) should have appropriate Java documentation {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>It's not mandatory to provide Java documentation for private declarations as these are rarely made public; if the intent
and purpose of the code is clear, Java documentation may be omitted for private declarations.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#cc0000">[Disallowed]</span> Use of @author within documentation comments {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>This avoids creating the perception of a single owner, rather than a team; it avoids a single developer being targetted to
undertake support.  If necessary, programmer or editor information can be obtained from the source code control
system's logs.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#cc0000">[Disallowed]</span> Within comments, the inclusion of amendment history or modification logs from source control repositories {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Source control repositories contain this information and access to this is readily available; including this information in
source files simply makes the file more verbose and obfuscates the code.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#000000;font-size:larger;">
<br>Declarations</span>
  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Standard order of declarations must always be followed for any .java file; declarations must always be preceeded by appopriate JavaDoc comments {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
The following order must be adopted:
</p>
<ul>
<li>
Standard HSBC copyright message
</li>
<li>
Package declaration
</li>
<li>
List of imported classes 
</li>
<li>
The class or interface declaration
</li>
<li>
Constants (static final), in the order of public, protected, package then private
</li>
<li>
Inner classes if being provided, in the order of public, protected, package then private
</li>
<li>
Class variables (final), all private
</li>
<li>
Instance varaibles, all private
</li>
<li>
Constructors, in the order of public, protected, package then private
</li>
<li>
Methods
</li>
</ul>
<p>
All classes, interfaces, constants, variables and methods must be preceeded by an appropriate JavaDoc comment, with
methods using the <code>@param</code>, <code>@return</code> and <code>@throws</code> tags as appropriate.  If
an implemention comment is required, this followed immediately after the declaration.  For example:
</p>
<p style="MARGIN-LEFT: 50px; MARGIN-RIGHT: 50px; BACKGROUND-COLOR: #f0f0f0">
<code><span style="COLOR: #007090">/**<br>
 * JavaDoc comment...<br>
 * @version $Revision$, $Date$<br>
 */</span><br>
public class Account {<br>
<span style="COLOR: #009000">   /*<br>
    * implementation comment...<br>
    */</span><br>
<br>
   ...<br>
}<br>
</code>
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> All class variables, instance variables and non-static constants are private {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>The sole exception is where class constants (static final) which cannot be modified by client code, and where they provide
benefit being exposed publically.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Interfaces must only contain methods {pmd}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Never include attributes or constants within an interface, which aids the promotion of the constants interface
anti-pattern.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Only one declaration per line is permitted; lines do not contain a mix of delcarations and statements  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
The sole exception to this rule is the <code>for</code> loop construct which permits loop variables to be declared as
part of the construct itself.
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Mulitple variables must never be assigned in a single statement; avoid chaining assignment operators {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> All variables must be explicitly initialised prior to use; do not rely on Java's in-built zero or null default {fb}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>For most variables, these should be initialised at the point they are declared, but prefer lazy initialisation if this
would cause possible performance issues or where the initial value is generated from some logic or calculation.  Take
care where varaibles being reused within loops must be re-initialised on every loop iteration.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Variables must always be used for a single purpose  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Declare constants within classes only; never use interfaces to only expose constant values {pmd}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>This prevents the "constants interface" anti-pattern. Where the class contains nothing other than constants, ensure the
class is final to prevent derivation, and include a private constructor to prevent instantiation.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Declare constants with clear ownership  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Always declare constants such that a clear ownership and "client-ship" is evident. For example, constants used by many
classes within a package should be declared within their own class within that package. A constant used by a single class
should be declared within that class. Take care, however, in those instances where a constant is owned by one class but
used by others. For example, API constants should be declared alongside the API and not the implementing class; an
internal constant giving a data storage key should be declared in the (single) class that populates (and clears) the
data store.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Declare constants as static and final  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Constant values must never be changed, so always enforce this at a code level. Always include static to ensure constants
are accessible without needing a class instance.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Always implement type-safe enumerations  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>There are two acceptable formats: for Java 5.0 and above use the intrinsic language support, for Java 1.4.x and earlier,
use the type-safe enumeration pattern. However, remember that this pattern has a couple of drawbacks: it's quite verbose
and therefore error prone, and it's constants cannot be used in switch statements. Where appropriate make the constant
class final to prevent derivation; always include a private constructor to prevent construction.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Expose setters and getters for publically modifiable state; always follow the JavaBean standard  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Not all properties need to be exposed as setters and getters, but a lot of object state information will benefit by being
at least readable.  When following the JavaBean standrads remember that getter methods are prefixed with "get" or
"is"; setter methods with "set".  For example <code>getName</code>, <code>setName</code>.  Note that this
requirement means these (usually simple) methods automatically follow the verb-based requirement.  Where setters
and/or getters are not being provided, pay special consideration to any testing requirements to enable appropriate JUnit
and/or JMock (etc.) to be created; consider providing overloaded constructors to enable non-modifiable properties to be
specified at construction time.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[Recommended]</span> Prefix boolean deterministic methods with "is"  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Deterministic methods are those that return an boolean indication that something has been done, something has happened or
the result of some condition.  For example, <code>isDirty</code>, <code>isPrinting</code>.  Historically, "has"
may also have be used and choice over "is" or "has" was based on grammatical and aesthetic reasoning, however it's
preferable to be consistent and utilise "get" or "is" (dependent on naming and context) as this permits Jakarta
Common's <code>BeanUtils</code> to be used with the object.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[Recommended]</span> Avoid overloading methods based solely on argument type rather than number of arguments  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Java method resolution is static and overloaded methods are resolved at compile time based on the declared type of the
parameter and not the actual (derived) type of object being passed.  This could lead to a number of unexpected flaws
where the method resolution doesn't work as expected when dealing with generic objects, and both generic and specific
overloaded methods are provided.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[Recommended]</span> Declarations should always be placed at the start of a code block using the smallest possible scope  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
Always avoid any use of global variables. Remember that attributes within a class can be visualised as variables that
are global to all the class methods; ensure that class attributes are truly attributes of the class and are not being
used purely for inter-method communication. Don't use the "constants interface" anti-pattern: this simply makes a
number of constant values (and their identifiers) globally available within a class. Always declare local variables
within method processing to have the smallest possible scope, without being redefined and re-instantiated excessively:
never declare variables inside loops. 
</p>
<p>
Declarations should always be placed immediately after the curly brace { when opening a new block of code (blocks of
code are opened immediately after the method declaration and as part of conditions and loops).  The single
exception to this rule is that "temporary" variables (used in a transient manner to store interim results) be may
declared at the point of first use.  In all cases, the objective is to make the code as readable as possible and
the intent clear. 
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[Recommended]</span> Avoid creating constants for literals with common meaning: 0, 1, -1 and null  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
These literals may appear directly in code without the added complexity of a delcared constants, providing they are
being used as "dummy", "termination", or "no value" type values.
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#cc9900">[Permitted]</span> Abbreviations in names; try to avoid abbreviations, but where abbreviations are being used follow the declaration's standard case  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
For example, prefer class names <code>UrlRedirect</code> rather than <code>URLRedirect</code>, or variable names
<code>validatedUrl</code> rather than <code>validatedURL</code>.
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#cc0000">[Disallowed]</span> The declaration or variables that hide declarations at a higher level {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>In other words, do not create local variables within methods with the same identifier as instance or class variables;
declare local variables with unique identifiers from each other.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#cc0000">[Disallowed]</span> Prefixes to declarations or types (including all classes, variables and methods) according to their type; do not use hungarian notation.  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>In other words, <b>do not</b> use prerfixes such as <code>I</code> to identify interfaces, <code>sz</code> to prefix
Strings, <code>win</code> to identify window types, etc.  These have no place in Java, and create issues when
refactoring code or changing the types of objects and variables.  Create class types to identify similar objects,
rather than using hungarian notation of integral types.  Contrary to popular belief, hungarian notation documents the
<em>logical</em> type rather than the physical type of a variable; in Java, this can be acheived through class types
(possibly) augmented with interface declarations.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#cc0000">[Disallowed]</span> Prefixes and suffixes to delcarations or types (including all classes, variables and methods) according to their location in the architecture  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>In other words avoid the use of names which tie use of classes, interfaces, variables, etc. to their implementations,
clients, or specific elements of the design.  For example, avoid names such as <code>PaymentsDao</code>,
<code>FsdtAe56Message</code>, <code>PaymentResponse</code>, etc.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#000000;font-size:larger;">
<br>Statements</span>
  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Only one statement (simple or compound) per line is permitted; lines do not contain a mix of delcarations and statements  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
The sole exception to this rule is the <code>for</code> loop construct which permits loop variables to be declared as
part of the construct itself.  Never use the comma operator to combine mutliple statements.
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> The return statement does not use parenthesis unless wrapping an expression {pmd}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
The <code>return</code> statement is that... a statement.  It doesn't need parenthesis around the specified
variable or value.  However parenthesis should be used where is makes the intent more clear; usually this will
occur when the return value is determined through some form of expression.
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> When chaining if-else statements, the consecutive else and if statements are co-joined on the same line  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
Basically, when the <code>else</code> contains a single <code>if</code> statement, the braces are omitted and the
resulting <code>} else if ...</code> is treated as part of the original if statement, rather than a separate statement
in it's own right. This applies to all aspects of the aspects of the chained if-else statement.
</p>
<p>
The Sun Java code conventions provide examples.
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> When chaining if, else if, else statements always code for the most common case first  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Avoid negative-stance conditionals; prefer positive-stance {pmd}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>That is, avoid inverse-stance conditions which generally work against the reader of the code, and write conditions in the
format they would be spoken. This is particularly true for if statements, but also applies to conditionals in while and for
loops. Remember that the subject should be clear, come first and be handled within the subsequent statement block.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Within a switch statement, never let control "fall-through" from one block to another; every case must have a break statement {pmd}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
The sole exception to this rule is where switch conditions are being "stacked" to execute common (but identical)
processing for a set of known values.  All further exceptions to this rule they must be justifiable in
context, and a single-line comment must be added in place of the <code>break</code> statement to indicate that the
fall-through is intentional.  However, in these instances consider the use of private methods to factor out common
processing.
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Every switch statement must include a default case {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>An accordance with other guidelines, the default case must also include a break statement.  If the default is not
required, still include the default case, but add a comment that indicates that this default case does not need to
undertake any processing (but at least it was considered and is not a bug), or if the default is never expected to be
executed throw an internal programming exception (defensive coding against bugs, which would clearly highlight
the issue when tested).</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Don't abuse the flexibility of loop statements  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>It's possible that the <code>for</code>, <code>while</code>, and <code>do/while</code> statements can be written to avoid
the need for any compound statement.  In instances where this is being done, <strong>never</strong> sacrifice
readability.  Remember that the two semi-colons are always required in <font face="Courier New">for</font> statements,
even if the initialization, condition and/or update are being omitted.  Where using multiple variables in for-loop
structures, in conjunction with the comma operator, limit the number of varaibles used to 3.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Minimize branches and decision points in code; attempt to keep the cyclomatic complexity low {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Increasing the number of decisions points within a method increases the method's complexity. This in turn increases the
amount of required testing, number of test cases, and reduces the ease with which the method may be debugged. Increase
complexity also increases the chance of coding flaws; excessive complexity make it difficult to use junior and trainee
member of the team to undertake maintenance and support. Decision points are those introduced by the statements such as if,
else, while etc.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Make "sunny day" paths clear  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
Make it easy to distinguish between the sunny-day and exceptional paths. Clearly indicate the exceptional paths as
such. Keep the sunny-day path straightforward and uncluttered.
</p><br></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[Recommended]</span> Use for loops when initialising and updating loop control variables; use while loops for loops only with a conditional check {pmd}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>The benefit of for loops is that it collects all loop control in a single place, and allows the declaration of loop control
varaibles that are scoped to the loop itself.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[Recommended]</span> Prefer while over for when creating infinite loops {pmd}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Or to put this another way, prefer:
<p style="MARGIN-LEFT: 50px; COLOR: rgb(0,128,0); MARGIN-RIGHT: 50px; BACKGROUND-COLOR: #f0f0f0">
<code><span style="COLOR: #0000ff">while</span> (<span style="COLOR: #0000ff">true</span>) {<br>
   ...<br>
}</code>
</p>instead of
<p style="MARGIN-LEFT: 50px; COLOR: rgb(0,128,0); MARGIN-RIGHT: 50px; BACKGROUND-COLOR: #f0f0f0">
<code><span style="COLOR: #0000ff">for</span> (;;) {<br>
   ...<br>
}</code>
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#cc0000">[Disallowed]</span> Embedding the assignment operator within a condition or statement {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
In these instances, and when maintaining the code, it's difficult to determine whether the assignment was required, or
whether that's a letent bug/typo which has been undiscovered.  Assignment statements should always be on their own
line, as a single statement.
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#cc0000">[Disallowed]</span> Modification of for-loop control variables within the loop itself  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#cc0000">[Disallowed]</span> Use of goto, break and continue statements within loops and code; code design should allow loops to run to completion {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Avoid using statements such as break and continue to jump around a loop's processing; avoid use of goto to skip over
processing, or exit multiple nested loops. There may be times where these constructs add value, especially when executable
size and speed are essential on mobile device's thick clients, but they are generally indicative of bad design for standard
Java development.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#000000;font-size:larger;">
<br>Naming Conventions</span>
  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Name classes and interfaces using nouns (common or proper) according to their type or behaviour; consider adjective-based interface names  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
Classes always follow a noun-based approach, adjectives are never used; for example, <code>CheckingAccount</code> (type
approach) or <code>CodeValidator</code> (behaviour approach).  Interfaces may use a noun- or adjective-based
approach, with adjectivies usually ending in "able"; for example, <code>Validatable</code>, <code>Observable</code>,
etc.  Use adjective-based naming when the interface exposes and identifies behavioural poperties than can be
applied to a class.
</p>
<p>
Where relationships exist, follow a most-specific to most-generic order to the class name elements, such as
<code>Account</code>, <code>CheckingAccount</code>, <code>NoFeeCheckingAccount</code>.
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Classes and interfaces use TitleCase, with capital letters used to identify the start of all words {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Name methods and operations using verbs  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Methods and operations always follow a verb-based approach; for example, <code>getName</code>, <code>send</code>,
<code>calculateBalance</code>, etc.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Name variables according to their role and association, avoid noun-based naming for local variables  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
The <em>type</em> of the variable provides a noun-based type that indicates what the variable contains, the name of the
variable should indicate the purpose of the value.  For example, prefer <code>accountOwner</code> rather than
<code>name</code>, or <code>requestedRedirect</code> rather than <code>url</code>, etc.  Occasionally
noun-based naming may be acceptable where integral types are being used; for example <font face="Courier New">int limit</font> or <font face="Courier New">boolean overdraftAgreed</font>.  <b>Do not</b>
name variables after their type (for example, <code>Url url;</code>, is not acceptable).  Use judgment and common
sense to make the code readable, and the intent clear.
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Methods and variables (non final) use camelCase, with capital letters used to identify subsequent words {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Name constants (including enumeration attributes) according to their roles and association  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Constant name should indicate the purpose of the value that informs the user of its intent of use; for
example, <code>GBP_DECIMAL_PLACES</code>, <code>MAX_LIMIT</code>, <code>IMMEDIATE</code>. Note that constant names
such as <code>ONE</code>, <code>CONSTANT_TWO</code> etc. which specify the value of the constant <b>are not acceptable</b>.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Class constant (final) variables use CAPITAL_LETTERS, with underscores to separate words {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Local (method) final variables use camelCase and follow local variable naming conventions {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Exception classes are always suffixed with the term "Exception" {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
Note that this automatically makes the class name follow the noun-based requirement.  For example,
<code>HighValuePaymentException</code>.
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#000000;font-size:larger;">
<br>Programming Practices</span>
  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Declarations must always have the smallest visibility and accessibilty needed, based on application design  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>In other words, ensure the internal logic uses private visibility, irrespective of the type of declaration (variable,
method, class, etc.).  Make full use of package visibility for classes that provide non-public package specific
functionality.  Use protected only where methods are expected to be overriden, and make public methods final where
derived classes must never override the original definitions in parent classes.  Always make classes final where they
should never be overridden.  Always try to minimize what's exposed publically (ie. provide a conhesive and concise
API) so that future enhancements and changes can be implemented more easily, as consideration to client usage is limited to
the public elements.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Use instance variables to store object state; do not use instance or global variables to pass results between methods  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
For data specific to methods (not the object's state), input parameters/references and return values/references must be
used to pass data between methods.  Only use instance variables to represent the object state; methods must only
change the values of instance variables where the object's state changes.  Similarly only use class variables
where the object class provides state, or to facilitate class-level functionality.  Never use use instance or
class varaibles to pass data between methods, or to store local results from method processing which can be equally
represented and fulfilled through local variables.
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Always use the class-name prefix to access class variables; never use an object instance to access a class variable {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
This makes access to the class variable explicit, avoiding possible conflicts with local variables (and the
introduction of bugs) where the data is being hidden.  For example, use <code>Foo.NAME</code> (or
<code>Foo.name</code> for non-constants) rather than <code>NAME</code> (or <font face="Courier New">name</font>)directly.
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Always use "this" prefix to access object instance variables {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
This makes access to the instance varaible explicit, avoiding possible conflicts with local variables (and the
introduction of bugs) where the data is being hidden.  For example, use <code>this.name</code> rather than
<code>name</code> directly.
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Avoid use of 'magic' numbers and other hard-coded data and static elements {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
If static or hard-coded data is required, use constants to convey the meaning and purpose of that data; for example,
<code>return SUCCESS_RESULT</code>, <b>not</b> <code>return ONE</code> which specifies the constant value. 
The sole exception to this is the use of <code>-1</code>, <code>0</code> and <code>1</code> which convey
appropriate meaning in their numerical context, and <code>null</code> where object references are being used. 
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Be liberal with parenthesis; don't assume everyone understands operator precedence  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Remember that not every developer is familiar with the rules concerning operator precedence, and additional explicit
parentheses only serve to make the code more readable; they add no overhead in terms of performance, but can prevent any
number of coding flaws where precedence rules are misunderstood.<br></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Be null-safe in code that may use null  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Generally speaking NullPointerExceptions should only be thrown on programming bugs and flaws; during execution in
production environments this exception does not provide sufficient information to diagnose the root cause of the
problem.  For code where null values may be encountered always be null-safe; from a defensive coding perspective,
consider being null-safe even in code that may not raise null references.  In these instances throw alternative
exceptions and log appropriate error mesages that indicate the root cause of the error to aid diagnosis in production
envionments.  See <a class="elementLink" href="./../../../hsbc.content.software_eng.guidance.java/guidances/checklists/using_exceptions_D207B1C8.html" guid="_Nm37wIcpEd6fdK0VTYUJ6g">Using Exceptions</a> for more specific guidelines.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Develop defensive and robust resource handling  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Remember to use proper locking to avoid concurrent updating of the same resource (including filesystem structures and
files). Use try-finally blocks to ensure all resources are always closed, even when exceptions are thrown. Always close a
resource if it supplies any form of closure or destruction method; there's no guarantee that will be called when the object
is destroyed, and there's no guarantee (if that's not the case) when an object would be destroyed.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Methods must be atomic; every method must undertaken only one action/operation and have a specific purpose  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Methods should undertake specific actions, with other methods providing co-ordination of lower-lever methods to achieve a
desired result. Together a set of class methods should provide a cohesive set of functionality. Methods which undertake
multiple tasks are harder to maintain. Where the same code is being duplicated in more than one location, look to refactor
methods such that common methods or utility classes are created that promote code reuse; remember that
methods which implement a single specific action are generally more reusable than methods which do not. 
Special consideration should be given to methods which do not need to be called by multiple clients: are those methods
really required; do they add value to the design?</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> All methods should have a single exit point at the end of the method {pmd}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
The single return point should be a return statement where the method returns a value or reference; this would be the
last statement of the method body.  Allowable exceptions may be permitted where the code becomes unreadable when
attempting to follow this rule.  If breaking this rule due to readability concerns, always make sure the structure
of the code is obvious and that all return statements are clearly visible.  Before breaking this rule, do consider
whether alternative implementation design may resolve the readability problem.  Never include the return
statement inside a try, catch and/or finally block; always place the statement outside any exception handling
logic. 
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> When providing multiple constructors, create a single "main" constructor and have all other "convenience" constructors call the main constructor  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> Consider the unit tester when implementing methods  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Put another way, look to design classes and methods to be easy testable through JUnit easily. Avoid designing classes that
have hidden state (private member variables that cannot be accessed by getters and setters), unless that state is being
exposed directly through atomic operations on other methods. Ensure classes do not depend on external factors, or where
this is not possible allow those external factors to be stubbed and/or mocked and the appropriate dependencies set via
appropriate getter and setter methods.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[MANDATORY]</span> All code must support localization  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Never make any assumptions regarding the user's locale in code. For example, currency formatting should always be
undertaken using the correct formatters and Currency objects; never assume a two decimal places are valid. Furthermore,
application code should pass around internal locale agnostic key values; messages from resource bundles should be looked-up
using the key values provided by the application code.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[Recommended]</span> Avoid the use of the ternary operator (?:); use if-else in its place {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>The sole exception to this is where a <strong>simple</strong> expressions are used to select one of two values. 
For example:
<p style="MARGIN-LEFT: 50px; MARGIN-RIGHT: 50px; BACKGROUND-COLOR: #f0f0f0">
<code>String result = (isCheckedOut ? "CHECKEDOUT" : "AVAILABLE");</code>
</p>Where complex expressions are used, ensure parenthesis are used to ensure the intent is clear.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[Recommended]</span> When creating threads, always provide the thread with a suitable name to aid debugging {cs}  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[Recommended]</span> Assign null references when objects are no longer required  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>When objects are no longer required, assign null to the reference variable if the object would otherwise hang around in
memory for a long period of time. Help the garbage collector know when objects are no longer needed.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[Recommended]</span> Prefer immutable objects for data  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Immutable objects such as <code>String</code> provide a number of advantages over mutable objects.  For example, they
prevent memory leaks when used as keys for caches, maps and sets; can improve thread-safety by ensuring read-only
operations are performed once they're created; and they enable references to be passed around without exposing possible
internally mutable state.  For a more in depth discussion on the benefits of immutable objects see <a href="http://www.ibm.com/developerworks/java/library/j-jtp02183.html" target="_blank">http://www.ibm.com/developerworks/java/library/j-jtp02183.html</a>.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[Recommended]</span> Validate public method arguments  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Validate supplied method arguments on all public methods, where the client's legitimacy cannot be ensured; don't validate
method arguments where Java will do implicit validation. For example, don't check for null arguments if the first operation
on that argument could generate a <code>NullPointerException</code>; do check for null arguments where other processing may
occur prior to that argument being used. Throw <code>NullPointerException</code> and derivatives of
<code>IllegalArgumentException</code> as appropriate to the contractual errors being detected. Ensure all exception text
includes a description, argument name, actual and expected values and ranges to aid debugging.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[Recommended]</span> Avoid exposing internal data structures; do not rely on client supplied data structures  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>For example, never store a user supplied collection directly or return a direct reference to a modifiable data structure;
in both instances, the client may directly modify this collection with the object being aware of any
changes.  When returning internal data values, and where the expense of copying large data structures between clients
and providers would become prohibative, consider use of the proxy objects which can inform the original owner of changes or
disallow updates to the data.  For example, for <code>Lists</code> and <code>Maps</code> consider returning a
<code>Collections.unmodifiableCollection</code> to prevent the client undertaking updates on the collection itself,
although be aware than any mutable objects within the collection could still be modified and this may not be suitable in
all instances.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[Recommended]</span> Apply well-known and well-defined patterns  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>Use the patterns described in these standards as a source of appropriate patterns. Using these patterns will
save time, increase code quality and facilitate code reuse. Consider additional patterns, such as those described by the
"Gang of Four", but remember that you may be developing functional- or service-based software so take care when considering
some of the more object oriented patterns as these may not be appropriate and may reduce the quality of functional based
code.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[Recommended]</span> Don't use Cloneable; provide copy constructors where appropriate  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>The Cloneable support has a number of intrinsic issues in respect to type-safety and exception handling; cloning data
structures is problematic where some data object do not support Clonable.  Prefer copy constructors over clonable
support, and when copying data structures within a copy constructor undertake appropriate deep copying where necessary.</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#009900">[Recommended]</span> Avoid recursive methods  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
Prefer non-recursive algorithms where possible; many non-recursive iterative mechanisms which use the standard
collection classes are more efficient during compilation and execution.  Where recursive functions are a necessary
due to better memory utilisation or faster execution, always prove and check for the base/stopping case
explicitly.  Always ensure pre-built versions of the algorithms are not available elsewhere, or provided by
third-party libraries such as Jakarta Commons.
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#cc0000">[Disallowed]</span> Coding and use of expressions and assignments that have side effects  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>For example, never use the ++ operators within conditions and/or assignments which make the intent of the code unclear</td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#cc0000">[Disallowed]</span> The modification of objects stored within Maps and Sets such that the value returned by hashCode or the result of equals is modified  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td><p>
Changing objects such that the hash code or equals behaviours changes while being stored in a Map or Set can lead to
memory leaks by preventing access to the object.  Where modification of objects may exhibit this behaviour, first
remove the object from the Map or Set, change the object such that the new hash code is created, and then add the
object back into the Map or Set.  Following this approach ensures that the data within the Map or Set is never
left in a corrupt state.
</p></td>
</tr>
</tbody></table>
</div>
</div><div class="stepHeading">
<span style="color:#cc0000">[Disallowed]</span> Reliance on finalize methods; use finalize methods for defensive coding measures only  </div><div style="">
<div class="stepContent">
<table class="stepTable">
<tbody><tr valign="top">
<td>The finalize methods should never be relied upon for critical resource cleanup. These methods are invoked by JVM before the
garbage collector reclaims memory associated with class instance, but there is no guarantee that these methods will be
executed in predicable fashion, in a timely manner, or even before the program terminates.</td>
</tr>
</tbody></table>
</div>
</div></td>
</tr>
</tbody></table>
</div>
</div>
</body>
</html>

乾朗

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
stand00

table {background-image: none;background: #ffffff;font-family: arial, helvetica, sans-serif, kanji2;font-size: 10pt;border : 0px;}.stepHeading {background-color: #ffffff;color: #
复制链接

扫一扫