Appendix C. Java Standards

 

A good developer knows that there is more to development than programming. A great developer knows that there is more to development than development.

 (Ambler, 1999)

The purpose of this document is to establish a set of standards for any code written in Java for use in WAF.

Why have conventions?

C.1. WAF Standards

In general, when programming for WAF, follow the Sun Java, JSP, and Javadoc conventions:

This chapter discusses WAF coding conventions where they differ from the Sun conventions or if they cover something that is not in the standard convention.

  1. Import statements should be alphabetized, separated into sections of relevant functionality, and enumerated without using *.

  2. All lines of source code should be indented uniformly using spaces and not tabs. Four spaces is the norm, although in some cases more space is required. Two spaces is forbidden under all circumstances.

  3. Class fields, unless constants, are private. A private field called foo is named m_foo. A static private field called foo is named s_foo.

  4. Exceptions are used to signal erroneous behavior or usage inside of a class. All stubbed methods should throw a runtime Error or UnsupportedOperationException with appropriate comments. Do not write generic catch (Exception e) blocks; catch the specific exceptions instead.

  5. Acronyms, such as JDBC or URL, should always be capitalized when used. For instance, write JDBCLoader instead of JdbcLoader. This makes it clear that the letters are part of an acronym and is easier to read because it matches how it is referred to in English prose. Abbreviations that are not acronyms should have their first letter capitalized, with the exception of ID.

  6. When debugging, avoid using System.out.println or System.err.println. Instead, use Log4j as described in Section 7.5 Using logging for debugging.

Notes

[1]

http://www.bartleby.com/141/.