Integrated Development Environment

An IDE provides not only a place to write code, but also to run that code and see the result. There are many features the Processing IDE offers, here are some:

  • Compile and run code
  • Save and manage projects (sketches)
  • Syntax highlighting
  • Console and message area for errors
  • Find and replace text
  • Auto formatting



Take a look around when you open up Processing. The environment is very minimalist. The play button will run your sketch and the stop button will stop it.

There are some extras you should learn right away:

  • CTRL (Command) R -> Run sketch
  • CTRL (Command) S -> Save sketch (do often)
  • CTRL (Command) T -> Format code (do often)


Processing will automatically create a folder for your sketch where you save it. All sketches must exist inside a folder with the same name as the sketch.
Here are a few golden rules about saving sketches:

  • Save often
  • Save as and make a new version when big progress has been made
  • Use a good naming convention:
    • Matt_Lockyer_Assignment1_Ver1
    • Matt_Lockyer_Assignment1_Ver2
    • Matt_Lockyer_Assignment1_Ver3
    • ...
  • Always put your name on an assignment sketch before handing in

Hello Processing

Printing a message to "Hello World" is one of the quintessential programming lessons of any language. Here's how we print out a message to the console with Processing:

print("Hello World");
And if we'd like the next thing we print to be on the next line:
println("Hello World");
println is short for print line


It is highly recommended you comment your code. This will increase your understanding by providing you with hints and tips about what the code is doing. Here's how to write comments:

//This is a single line comment
/* This
comment */

Comments are ignored by Processing when you press the play button.


RUN YOUR CODE OFTEN! This will help you identify when something is not working (the last thing you were working on). Do not try and implement a bunch of features in your sketch and then hit run at the end only to find out something went wrong.

Build a little, run, test, build more...

If something doesn't work. Change one and only ONE thing at time! This practice alone will save you hours of debugging time.

Debugging stands for removing errors from your code. Bugs in your code come in two varieties:

  • A compile time error (Processing Compiles and finds an error)
    • Usually caused by a syntax error
      • You mistyped something
      • You missed a bracket, semicolon...
      • You used a variable of wrong type
      • Variable name doesn't exist
      • Method call doesn't exist
    • Processing gives an instructive error message in the dark red message area
  • A run time error (Processing comiples, but the program crashes)
    • Usually accessing a variable that has not been initialized
    • Trying to access an array position greater than the size of the array
    • Logic errors (the code doesn't do what you expected it to)

"Bug" as a term for error or fault dates back at least to the 1870's. Edison used the term "bug" in one of his letters.

Always print out the value of variables in your program when things are not behaving as you expect. This is incredibly useful for finding the cause of runtime errors.

Tracing code is a valuable skill. To practice follow some code through its execution and watch the variables by printing out their values.


Bracket errors are the most difficult to find. Matching brackets for hours is a pointless and exhausting exercise.