
<style type="text/css">
      pre {padding:.2em; background-color:#F5F5DC}
      body {counter-reset: h2}
      h2 {counter-reset: h3}
      h3 {counter-reset: h4}
     
      h2:before {counter-increment: h2; content: counter(h2) " "}
      h3:before {counter-increment: h3; content: counter(h2) "." counter(h3) " "}

      h2.nocount:before, h3.nocount:before { content: ""; counter-increment: none } 

</style>

# Style Guide and Setup Instructions for CS 240

## Installing Java and an IDE

Java 21 is the officially supported version of Java for this course. If
you haven\'t already installed it, you can download the JDK from the
[Temurin download
site](https://adoptium.net/temurin/archive/?version=21).

There is no required development environment for this class. The style
section below includes instructions for configuring VSCode, Eclipse, or
IntelliJ IDEA to support the course style requirements.

-   [Visual Studio Code
    Downloads](https://code.visualstudio.com/download)
-   [Eclipse Downloads](https://www.eclipse.org/downloads/) (Install the
    \"Eclipse IDE for Java Developers\")
-   [Intellij IDEA Downloads](https://www.jetbrains.com/idea/download/)

## Google Java Style Guide

The most important role of a set of coding standards is *consistency*.
No group of programmers will ever completely agree on the best way to
format code. Should code blocks be indented with tabs? With spaces? How
many spaces? Two? Four? Eight? Where should opening braces be placed?
The fact is, none of these things really matter that much. What *does*
matter is consistency. It is very inconvenient for a group of people to
work together on a shared code base if they don\'t agree on some set of
common standards.

Code submitted for this course must conform to the [Google Java Style
Guide](https://google.github.io/styleguide/javaguide.html)
. We are using these standards because they are well documented, widely
used, and supported by development tools.

The Google style guide is mostly concerned with low-level formatting
issues like indentation and line length. Keep in mind that it is
possible to write *very bad* code that is properly formatted and will
pass automated checks. See Section 4 below for some additional style
requirements.

## Environment Configuration

### Configuring VS Code

Install the following extensions:

-   [Extension Pack for
    Java](https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack)
-   [Checkstyle for
    Java](https://marketplace.visualstudio.com/items?itemName=shengchen.vscode-checkstyle)

Uninstall or disable the following extensions. These are installed by
default with the Java Extension Pack, but we won\'t need them.

-   [Intellicode](https://marketplace.visualstudio.com/items?itemName=VisualStudioExptTeam.vscodeintellicode)
-   [Maven for
    Java](https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-maven)
-   [Project Manager for
    Java](https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-dependency)

Download and extract the file [CS240_F24.zip](CS240_F24.zip). Make sure the resulting folder is stored in a sensible location on
your computer: don\'t just leave it in your Downloads folder.

Now open the `CS240_F24` folder in VS Code. You should see the following
subfolders:

-   `.vscode` - settings and configuration files for CS 159
-   `bin` - binary files, which will be created automatically
-   `lib` - required libraries, such as JUnit
-   `src` - source files, where all your programs will go

Open `src/demo/HelloWorld.java`, and press F5 to run the program. VS Code
will open a Terminal window. The terminal shows: (1) the command used to
run the program, and (2) the program\'s output.

For each project or lab, you will add a new subfolder under `src`.

### Configuring Eclipse

#### Checkstyle Plugin

The Eclipse Checkstyle plugin can be installed by following the
instructions on this page:

<https://checkstyle.org/eclipse-cs/#!/install>

Once the plugin is installed, the Google style configuration can be
selected by accessing \"Window-\>Preferences-\>Checkstyle\" and
selecting \"Google Checks\".

#### Formatter

The Eclipse auto formatter can be configured to follow the Google
guidelines by accessing \"Window-\>Preferences-\>Java-\>Code
Style-\>Formatter\" and importing the following file:

-   [eclipse-java-google-style.xml](https://raw.githubusercontent.com/google/styleguide/gh-pages/eclipse-java-google-style.xml)

### Configuring IntelliJ IDEA

#### Checkstyle Plugin

-   Open Settings.
-   Find the Plugins panel.
-   Search for and install Checkstyle-IDEA.
-   Find the Tools / Checkstyle panel.
-   Select \"Google Checks\".

#### Formatter

The IDEA formatting preferences can be configured to follow the Google
guidelines by accessing \"Settings-\>Editor-\>Code Style-\>Java\" and
importing the following file:

-   [intellij-java-google-style.xml](https://raw.githubusercontent.com/google/styleguide/gh-pages/intellij-java-google-style.xml)

## Additional Style Requirements

### Names

Selecting informative names is one of the most important steps in
writing readable, maintainable, and correct code. Variable names should
clearly describe what the variable is intended to contain.

All names should be descriptive and readable: `subTotal` rather than
`s`; `grade` rather than `grd`. Variable names should balance clarity
with brevity. The name `person` is better than `currentPersonObject`.
However, `per` is worse than either (percentage? person? permitted?).

### Non-Javadoc Comments

The point of comments is to clarify code that might otherwise be
difficult for the reader to follow. Well organized Java code with
informative variable names should require few comments inside of method
bodies.

-   In-line comments must come before the code that they are describing
    or, if brief, on the same line following the code.
-   You must use normal English spelling and grammar. Phrases are okay,
    but cryptic abbreviations and unintentional misspellings are not.

### Honor Code and Acknowledgments

Every programming assignment must contain the following section which
follows the class description or must cite any sources used (such as a
TA). You should either include this statement in all files or minimally
it may appear in the file containing your main method.

          /*
              * This work complies with the JMU Honor Code.
          * References and Acknowledgments: I received no outside help with this
          * programming assignment.
          */
        

\
OR


          /*
              * This work complies with the JMU Honor Code.
          * References and Acknowledgments: TA Glenn helped me with the 
          * foo method.
          */
        

This acknowledgment is not necessary for lab assignments. Note the
single star after the slash; this is not a Javadoc comment.\

### Miscellaneous

-   It should be clear how and where a method exits. Some software
    developers insist on only a single return statement. That is a good
    rule of thumb, but does not always make code easier to read \-- as
    in a linear search algorithm, in which exiting directly from the
    loop is reasonable.
-   Avoid \"magic numbers\". Use named constants instead of literal
    values when you need to specify a constant value in your code. (e.g.
    `Math.PI` rather than `3.14159`)
-   Your code must not have unused variables or unnecessary statements
    (statements that do nothing).
-   Avoid the use of `break` and `continue` except in switch statements.
-   All instance variables should be declared `private` or `protected`
    unless there is a documented reason for not doing so.
-   All visibility modifiers should be explicitly stated.
-   Methods should not have undocumented side-effects. For example,
    print statements used for debugging should not be included in
    submitted code.
-   Unnecessary code repetition should be avoided. Create helper methods
    where they will simplify your implementation.


