Computer Science 225
Advanced Programming

Spring 2022, Siena College

Style Guide for CSIS 225 Programs

The way you present your program is almost as important as having a correct program. While having good comments or good variable names will not directly impact the correctness of your program, it will make it easier to read your program (and so, easier to write and to debug). It is important that others be able to understand your code so that they can modify your code if they have to.

As good style, formatting, and documentation are expected of programmers at your level, you do not earn points for these, but can be penalized if expectations are not met.

Use this guide to help you better understand style expectations. As the semester progresses there will be steeper penalties for styling mistakes. Get into the habit of writing good programs from the beginning. After writing your program, be sure to look over your code with the guidelines here in mind.


Your program should be formatted as neatly as possible.


Comments are extremely important. Take some care to write accurate yet concise comments. As you know, certain Java comments, those written in the Javadoc format, can be used to generate documentation in HTML format.

You should write comments for:

Naming Literals

Avoid "magic numbers", i.e., numeric constants, in your code. For example, rather than writing

        points = new Coords[10];

associate a static final variable with the number, defining a named constant:

        private static final int NUM_POINTS = 10;

and use the named constants in place of the numbers:

        points = new Coords[NUM_POINTS];

This way it is clear that the "10" means a number of points, and if you later change the number of points, you can do so in one place (the constant definition). This is much better than going through all of your code, trying to decide which of the many 10's sprinkled throughout need to change.

Not that the above would be used to declar a named constant declared for the entire class. A named constant local to a method would omit the "private" and "static".


You should always choose names that suggest the meanings of the things being named. If the purpose of a method is to remove all the blanks from a string, then a good name for that method is removeBlanks. If there is a variable of type int that is used to refer to the total number of turns left in a game, then a good name might be turnsLeft or remainingTurns.

Names that have nothing to do with the program are very bad names! For example:

    private PrintWriter c3po;

would be a poor name unless the PrintWriter is perhaps being used to create a file of quotes by a shiny gold protocol droid with a British accent.

Names that are not specific or descriptive enough are generally bad names. For example:

   double a;

would not be descriptive at all.

Try not to name objects sequentially. You should only do this when the objects are related in some way that is not otherwise expressible in a meaningful way. For example,

   JButton button1;
   JButton button2;
   JButton button3;

are not as good as

   JButton startButton;
   JButton pauseButton;
   JButton resetButton;

if they are being used to create buttons that start, pause, and reset a simulation, for example.

One exception that is generally accepted is to use simple variable names like i and j for the index variables of for loops. However, even in those cases, it is often better to use a more descriptive name (e.g., row, studentNumber, word) if it will make the code more clear.

Naming Conventions

The Java compiler is quite flexible about the names given to identifiers like class names, instance and local variables, and named constants. However, by convention, Java programmers (including us) will follow these rules:

Whenever possible, names should be declared as local variables rather than instance variables. Instance variables should only be used when a value need to be persistent, i.e., saved for use after the execution of a method or constructor is completed.

Appropriate Use of Language Constructs

There are many instances where there are multiple correct ways to write a section of code. Often, there is little advantage to one over another. However, we will aim to use the most appropriate construct in those cases where one is more appropriate than another.

Loop Constructs

We will use three main loop constructs this semester: the while loop, the standard for loop, and the enhanced ("for-each") variant of the for loop.

Guidelines: When waiting for some condition to become true, such as a value to exceed some limit, or for a valid file name to be entered, a while loop is most appropriate. For counting, a for loop is most appropriate. When iterating over all of the items in a collection such as an array or an ArrayList, either a standard or enhanced for loop is appropriate.


Programmers often write boolean expressions in conditionals and loop constructs that are based on the value of a boolean variable. For example:

  if (numberEntered == true) {
      // do something


  while (done == false) {
     // do something

These are error-prone practices, as even highly experienced programmers could mistakenly write:

  if (numberEntered = true) {
      // do something


  while (done = false) {
     // do something

Normally, Java complains if you use an assignment operator where you meant to use a comparison for equality in a boolean expression. But in this case, since the assignment is to a boolean variable, the assignment itself evaluates to a boolean and is perfectly valid Java. But think about what's happening here. The if statement will always execute the "do something" block, since the statement both sets numberEntered to true and evaluates to true. In the while loop, the body of the loop can never execute, since done will be set to false and the condition will evaluate to false.

The better way to write these, to be more concise and to avoid these potential errors:

  if (numberEntered) {
      // do something


  while (!done) {
     // do something

Assigning a boolean Variable

Another common code pattern that should be avoided is the following:

  if (someBooleanExpression) {
      booleanVar = true;
  else {
      booleanVar = false;

While the above is correct, it can be written much more concisely (and to generate more efficient code), as follows:

  booleanVar = somebooleanExpression;

Git Commits and Messages

Whether collaborating or not on a given programming task, you will be expected to make effective use of Git for version control. As you design, implement, test, and debug your programs, you should be making commits of each small change you make, and should use a meaningful commit message.