Course Coding Standards

Why do we Need a Coding Standard?

When you started coding you were focused on just getting everything typed correctly and figuring out what it all meant. And then you saw the code was pretty short and simple and you understood it all so as long as it was typed right, nothing else mattered.

As code gets longer, it gets harder to figure out what it does by just glancing through it. This is even more true if you are looking at code someone else wrote. This is why professional coders tend to follow certain standards with how they write their code. This way when they look at each others code, it is easier to read. When you are writing code, you should always think about what others would think if they read your code.

Indenting and Curly Braces

Coders have spent a lot of time arguing and debating and writing about different styles of indenting code. Wikipedia has a good summary.

The editor in OpenProcessing.org encourages a direction we are going to follow. Press the tab key to indent and it will give you an indent that is 2 spaces over. Don’t press space twice to indent. Just use the tab key.

Whenever you have code inside of curly braces, you indent within the curly braces. If you nest the curly braces, you keep indenting like this:

function power(x,y) {
  var result;
  if (y &lt; 0) {
    result = 0;
  } else {
    result = 1;
    while (y &gt; 0) {
      result = result * x;
      y = y - 1;
    }
  }

  return result;
}

function power(x,y) {

var result;

if (y < 0) {

result = 0;

} else {

result = 1;

while (y > 0) {

result = result * x;

y = y - 1;

}

return result;

}

Curly braces start at the end of the line starting the function, conditional or loop instead of on the next line.

Also note in the if statement how the else is between the close and open curly braces.

Curly braces nest backwards so you will often see this:

{
  {
    {
    }
  }
}

{

}

If you write longer code, it may be helpful to comment the closing curly braces to make it easier to see what they are closing. Like this:

  } // end of some if statement far above
} // end of function foo

1 2	} // end of some if statement far above } // end of function foo

Comments

Comments are reminders to you and others about what your code does. You can have too many comments but that is usually when the comments don’t communicate clearly what the code does.

Every function you write must have a comment describing it’s purpose indented on the line below the function declaration like this:

function findFreePoint(arr) {
 /*
 find an available space in the array for a new particle
 */
 for(var i=0; i&lt;maxPoints; i++) {
   if(arr[i] === -1) {
     return i;
   }
 }
 return -1;
}

function findFreePoint(arr) {

find an available space in the array for a new particle

for(var i=0; i<maxPoints; i++) {

if(arr[i] === -1) {

return i;

}

return -1;

}

It is encouraged to write comments elsewhere in your code to describe what sections of code do. For example if there is a block of code that draws a part of your shape, add a comment that says what that part is. It makes it easy to find later.

You should comment your variable declarations as well. If we can’t tell what a variable is for from reading its name, it needs a comment. For example:

var xPosition;
var yPosition;
var xSpeed;
var ySpeed;
var dwIM; // this one needs an explanation :-)

var xPosition;

var yPosition;

var xSpeed;

var ySpeed;

var dwIM; // this one needs an explanation :-)

Variable and Function names

When naming a variable or function, start with a lower case letter and capitalize any additional words in the name. This is called Camel Case (or camelCase). Examples:

var i;
var maxPoints = 500;
var rPoints = [];
var wind;
var windMax = 4;

function setup() {

}

function createNewPoint(startX, startY) {

}

function pleasedontwritefunctionnameslikethis(noReally, dont){

}

var i;

var maxPoints = 500;

var rPoints = [];

var wind;

var windMax = 4;

function setup() {

}

function createNewPoint(startX, startY) {

}

function pleasedontwritefunctionnameslikethis(noReally, dont){

}

In Conclusion

There are other styles of coding. The most thing is readability and consistency. If you are on a team, it is best if everyone on the team follows the same standard. Thus, this page defines the standard for this class.