Basic Coding Standards
Every “programming shop” has established coding standards. The following standards are used nearly
universally. These standards, in general, can be (and are) applied to all languages, across all industries,
and in all organizations. All code you submit in IS2041/IS2043 for a grade must adhere to all of the
following standards.
Contents
Import Statements ............................................................................................................................................................... 1
Variables .............................................................................................................................................................................. 1
“Descriptor” Code – Code that Describes Objects ...................................................................................................... 2
Constructor Methods........................................................................................................................................................... 2
Get and Set Methods ........................................................................................................................................................ 2
Other Class Methods.......................................................................................................................................................... 2
Coding Style/Usage Notes .............................................................................................................................................. 2
Naming Conventions ...................................................................................................................................................... 3
Class Names ............................................................................................................................................................... 3
Method Names ........................................................................................................................................................... 3
Names of Constants .................................................................................................................................................. 3
Variable Names ........................................................................................................................................................ 3
White Space ........................................................................................................................................................................ 3
Comments ............................................................................................................................................................................. 4
Import Statements
•
•
•
Code will not use/include full-package imports. For example, import java.util.* or import
java.nio.*. Such coding indicates the coder does not know/understand which source files are
needed. It also diminishes the readability and maintainability of the code.
Organize import statements in some way. Possible organization schemes include alphabetical
order by class / interface name within package or by related function (I/O v. collection
management).
Include only necessary import statements. “Dead” or unused import statements will incur point
penalties in submitted work.
Variables
•
•
•
Organize declarations of class instance variables. The default organization should be the order
used in the associated UML Class Diagram. Other organization types include by type or
alphabetically. The preferred organization is by UML definition.
Scope all variables as strictly as possible. Declare variables globally only at absolute need.
Include an explanation of why a global declaration was necessary or preferred.
Handle class (instance) variables only through the appropriate get and set methods.
Java Coding Standards
© 2019, Terri Davis
1 of 4
“Descriptor” Code – Code that Describes Objects
•
•
•
•
•
•
Descriptor code will never perform any sort of input or output operations.
There will never be import statements in descriptor code for Scanner, Formatter, or other
input or output (I/O) handler types.
Descriptor code will never include System.out or System.err calls/references.
Descriptor code will never include a main method.
Descriptor code will include definition of instance variables.
Descriptor code will contain one or more constructor methods.
Constructor Methods
•
•
•
Constructor methods will be coded immediately following class (instance) variable declarations.
Always include a default (no-parameter or null) constructor (unless specifically instructed
otherwise); the default constructor should always appear as the first constructor.
Constructor methods will not set variable values directly. Constructors must call the appropriate
set method for each instance variable. This rule also applies when setting default values for
instance variables.
Get and Set Methods
•
•
•
•
•
Declare set and get methods for all non-static class variables.
Declare all set and get methods as public and final.
Code set and get methods after constructor methods and before any other methods are
declared.
Set and get methods will be organized in one of two ways:
1. All set methods first, followed by all get methods, in the order of declaration of the
associated instance variables.
2. The set method followed by the get method for each instance variable, in the order of
declaration.
Set and get methods will be named using standard conventions:
1. The word ‘set’ or ‘get’
2. Followed by the instance variable name
3. Casing adjusted for camel-casing standards.
Other Class Methods
•
•
•
Where reasonable, declare class methods as private.
Organize class methods in some recognizable fashion. Organization options include by purpose,
call order, or data source.
Every descriptive class should include a toString method.
o Always declare the toString method as public.
o The toString methods should be the last method defined in a class source file.
Coding Style/Usage Notes
•
•
Write code for this course to be clear and easy to read, first and foremost. Efficiency is nice, but
clear, readable code is the priority here.
Use of the keyword “this” is expressly forbidden in all code produced for a grade in IS 2043.
Java Coding Standards
© 2019, Terri Davis
2 of 4
Naming Conventions
Class Names
•
•
•
•
•
•
Class names begin with a capital letter.
Names of classes describing objects (types) will be nouns. For instance: Book, Student, Account,
Contract.
Names of interfaces will also be nouns (these may be plural nouns); alternately, adjectives may be
used.
Names of classes processing objects will use verbs. For instance: TestHierarchy,
ProcessReport, BuildFile.
“Helper” code that supports serialization or other ancillary object functions will use a plural noun.
For instance: Books, Students, Accounts, Contracts.
Custom comparators should use the name of the object type they address, followed by an
underscore, followed by the name of the instance variable used for ordering. For instance:
Book_Title, Student_Gpa, Account_AcctNbr, Contract_ContractId.
Method Names
•
•
Method names begin with a lowercase letter.
Method names use verbs: withdraw, deposit, updateBalance, setName, getRate.
Names of Constants
•
•
•
When used, name constant values in all capitals, with underscores to separate the words.
Examples: TAX_RATE, TUITION_PER_HOUR, ARRAY_LIMIT.
Always declare constants as final.
Variable Names
•
•
•
•
•
Single-character variable names (x, i, a, etc.) are NEVER acceptable. Each use of a singlecharacter name will trigger a minimum deduction of 5 points.
Use singular nouns as variable names. For example: title, taxRate, customerNumber.
Variable names should be meaningful and/or descriptive. If a variable is used for counting
something (loop executions, for instance) use something like counter for the variable name.
Variable names should be easy to read and clear. An abbreviation such as cntr may be easier
to type, but may not be clear to someone else reading your code.
Naming of variables will follow general Java conventions – specifically the use of camel-casing.
White Space
•
•
•
•
•
•
“White space is good.” It adds greatly to the readability (and therefore, maintainability) of your
code.
White space has no effect on compile time, performance, or the size of a distributable object. Be
generous with white space.
Break up instructions/statements into multiple lines when the statement would otherwise require
scrolling right to see all the code.
Break up instructions to add clarity and provide for ease of reading/parsing.
Insert at least one blank line between the class/method header and the code that follows the
header. (This “blank line” may contain the opening brace, but no other code.)
Separate groups of variables (instance or method) with a blank line.
Java Coding Standards
© 2019, Terri Davis
3 of 4
•
•
Separate methods by one or more blank lines.
Use indentation to help illustrate/define scope within methods and classes.
Comments
•
•
•
It is impossible to over-comment code. Good commenting will make your code much easier to
read, maintain, and reuse.
Comments are ignored by the compiler and do not add to the size of the executable code.
Minimum comment requirements for any/all code submitted:
o For each class:
 A short description of the class, above the header.
 A short explanation of the purpose of the class, above the header.
 An outline of class variables, above the header – or – beside each variable
 An outline of class methods (set and get methods may be excluded here)
o For each instance variable:
 A short description of the variable
 Valid values/ranges for the variable in question, as appropriate
 Comments should appear above or on the same line as the variable declaration
o For intermediate (method) variables:
 Short explanation as to why an intermediate variable is needed (i.e., its purpose)
 Where/how the intermediate variable will be used
 Comments should appear above or on the same line as the variable declaration
o For every method (including constructors):
 A description of the method and/or its purpose
 Parsing of the method header to include input parameters and return type
 An explanation of any specific processing taking place in the method (i.e., specific
formulas used)
 Comments should appear above the method header
 Comments should be included within the body of the method to describe the
processing taking place. The following should always be specifically commented
regarding structure and purpose:
• Loops – Description of the loop test, control, and processing
• IF statements – Description of the selection being made
• CASE structure – Description of the selection being made
Java Coding Standards
© 2019, Terri Davis
4 of 4