Java Coding Style Rules (be sure to use the Linux fjc
command to help format your code)
-
Naming Name things well in your code and remember
especially to start the name of any class method having a void return
type with a verb.
-
Formatting You can use the
fjc command on
your Linux account to format your code, but there are some rules to keep
in mind and follow when you are developing your code. It is important to
be consistent when formatting code, and be especially careful to ensure
the following:
-
All statements that are meant to be at the same indentation level
must be vertically aligned. Indentation levels are 4 spaces.
(Statements that continue beyond a single line may continue to use
this indentation level or use a modified level to enhance
readability.)
-
Matching braces that enclose code segments such as method bodies or
loop bodies must align vertically, and each brace must be on a line
by itself. The
fjc command will do this for you.
-
Appropriate vertical and horizontal spacing must be inserted and used
consistently for maximum readability. Ensure that blank lines are
inserted to separate “logical chunks” of code (putting a blank line
before each method, for example), and also that each operator in an
expression has a blank space on either side.
-
Your code must contain no TAB characters and no wrapped lines (so
lines must be strictly less than 80 characters in length).
-
You must use the proper style of capitalization for each kind of
program entity. (Class and interface names start with a capital,
while all methods start with a lowercase letter. Variables start with
a lowercase letter. Camel notation is used throughout. The one
exception to all of this is named constants, which use all caps and
underscores to separate words in the name.) Note that no editor or
IDE can enforce this … it’s totally up to you to follow this
particular requirement.
-
Commenting Indented source code file must have //
comments at the beginning for the ID information, a /* … */ comment for
the self-assessment, and (if required) Javadoc-style comments for
classes, method headers, pre-conditions and post-conditions, and possibly
other items as necessary.
-
If short, comments can be at the end of the same line as the thing
being commented. Otherwise, comments must be indented to the same
level as the thing being commented.
-
When in doubt, check the commenting style used in the
instructor-supplied sample code files.
-
Error Checking Your programs are not required to check
user input for potential errors and deal with them unless this is
specifically requested in the specifications for a submission. The
default is to assume that users will enter what they are asked to enter,
and if they don’t your program is not responsible for what happens next.
-
Miscellaneous Requirements
-
If getting and/or setting class data members is required, always use
getter and setter methods to get and set those values.
-
Make sure any submitted executable class or jar file displays the
proper identification when it runs.
-
Several short methods are virtually always preferred to one long one
(a long switch or nested if..else may be permitted).
The following is not an exhaustive list, since it is impossible to make a
list of all the things that might be wrong with a given program. However,
the list does give you some particular transgressions for which you will be
penalized if you commit them. In each case the marker has the discretion to
apply an initial penalty of at least 1 point, and sometimes 2 or more
points out of 30, depending on the severity of the transgression. In
addition, if you commit one or more of these transgressions and the marker
points out that you should not do so, and you then continue to do so, you
may expect to lose an increasing number of points for so doing, until you
correct the problem. In this context it is worth remembering that we are as
serious about style as we are about substance.
-
Missing self-assessment, which must be enclosed in
/* … */comment delimiters.
-
Comments that do not align with the thing being commented (except for
inline comments).
-
Wrapped lines (all lines must be < 80 characters in length and contain no
TAB characters).
-
Improper indentation levels (our indentation level is four spaces).
-
Improper statement alignment (which is likely to happen if you have TABs
in your code).
-
Matching braces that enclose a code block and are not aligned vertically,
with each brace on a line by itself.
-
Badly formatted method headers (see below).
-
A void method name that does not begin with a verb.
-
A method name that does not begin with a lowercase letter.
-
A named constant that is not all caps, with underscores as word
separators.
-
Poor variable naming or misuse of “camel case” spelling in program
identifiers.
Be careful to note, as well, that for any submission either a missing or
corrupted executable (that is to say, an executable that the marker is
unable to run, for whatever reason), or a missing or corrupted source code
file, will result in a deduction of 15 points (out of 30). In this regard,
make sure you do not submit an executable as source code, or vice versa,
since this is one way of “corrupting” your submission. Be sure to note the
sizes of the files you have submitted. The executable should always be
bigger than the source code file. It is not the responsibility of the
marker to correct mistakes of this kind.
An important additional note regarding print,
println and printf statements. Let’s illustrate
with println. To format a println statement that
is all on one line, it is as you would expect:
System.out.println("Some text to be printed here.");
But if the text to be printed causes the println statement to
extend over more than one line, the formatting must look like this:
System.out.println
(
"Beginning of text to be printed, and in this case there is more "
+ "text to be printed,\nand this text may go on for a while over "
+ "many more lines, with \n characters to insert line breaks."
);
Formatting of method headers must follow these patterns:
return_type method_name() //No parameters
return_type method_name(parameter_type parameter_name) //One parameter
return_type method_name(parameter_type parameter_name) //One parameter
return_type method_name(type1 par_name1, type2 par_name2) //Two parameters
return_type method_name //Three or more parameters (or even just two)
(
parameter_type1 parameter_name1,
parameter_type2 parameter_name2,
parameter_type3 parameter_name3 ...
)