You only write code once, but read it many times. Having clean, organized, legible, intuitive, and understandable code is important for those who read it: whether it be for debugging purposes (yourself, a peer, or a TA), for style grades (a TA), or even for judging your coding abilities and organization (a potential employer/co-worker). Yes, your code may run and solve a given problem whether it is organized or not. But, writing your code in a clean and organized way from the start will benefit you in the long run.
Code must compile: Any code you submit must compile. If it does not compile, we won’t grade the assignment and you will lose all the points for the assignment.
Don’t repeat yourself (DRY): If you find yourself writing the same or similar code two or more times, consider whether it could be put in a separate method.
Break up large methods: If a method has many parts doing distinct and non-overlapping functions, consider breaking up the method.
Don’t rewrite existing code: The Java standard libraries provide implementations of a great number of methods and data structures: use them! The java.util package will prove especially useful in this course.
Comments: Comment your code where necessary e.g. complicated functions, specifying method behaviors, stating invariants. When documenting methods, write Javadoc. Within methods, good style and good variable names are usually enough: don’t over-comment.
You should adhere to the Google Java Style Guide with the following exceptions:
The easiest way to format your code correctly is to understand the style guideline and get used to seeing code that looks good. However, most modern IDEs and text editors have code formatters, which we encourage you to configure and use (see below for instructions).
Upon submission, our grader will lint your code and point out anything wrong with your style, which you should fix.
Avoid public fields: Use getters and setters instead. If a class
an instance variable
x and you are working with a
Point point, you should
not find yourself writing
point.x. Instead, declare
x as a (package-)private
variable, and write a getter method,
point.getX(). One exception in which this
rule may be waived is if the variable
x is marked as
Use appropriate modifiers for all types: In general, restrict visibility as
much as possible. If need a refresher on
static), refer to the Oracle pages on
and instance/class members.
The Google Java Style Guide is widely used, and developers have created files to help automate the Eclipse Code Formatter setup. The CIS 121 staff has modified the original setup file to include the exceptions to the guidelines we expect you to follow (as listed above). We highly encourage you to setup this auto-formatter.
Window -> Preferences(Windows) or
Eclipse -> Preferences(Mac), select
Java -> Code Style -> Formatter
Import, and find the
eclipse-cis121-style-guide.xmlfile you downloaded in Step 1.
OK. You are all set!
Please go to Office Hours for help if you run into any issues.
Command + Shift + F
Control + Shift + F
Alternatively, you can do it the old-fashioned way through the main menu:
Source -> Format.
Warning: The auto-formatter does not catch and fix every style error, but it does fix the vast majority of them. You should be using the auto-formatter as a second line of defense.
Note: You can also setup the formatter so that upon saving a file, it auto-formats for you. Some people really dislike this feature as it can get annoying, but you can try it if you’d like. Instructions can be found here.