Standardized Coding PracticesStandardized coding practices establish a consistency between different software languages. The use of comments and white space (the space between the characters making up your code) form an important part of formatting your code to comply with these standards. If you do not use standardized coding practices your software may or may not throw an exception or an error, but you can be certain that there are many people that will take exception. Whether your code is intended to be used by yourself or by others standardized coding practices can contribute to the readability of your code and as a result it best to avoid trying to invent your own.
Comments are lines of information inserted between code that informs a person reading the code of it's purpose and intent. Comments are completely ignored by the software executing the code such as the PDE and they should be written in plain and simple English or, what ever your chosen natural language. Consider that the comments you write might not always be for your personal understanding but for another person reading your code and therefore should reflect a clear and impartial explanation of your code. Commenting your code becomes particularly useful for code that you have not revisited over a long period of time. Regardless of whether you wrote the code or not, trying to understand what revisited code is supposed to do after long periods of time becomes a cumbersome process when it is not commented properly. Comments in Processing and many other higher level languages (particularly those that are C based) are indicated with two forward slashes:
Comments that are more than one line long are called multi-line comments in some programming languages and documentation comments in Processing. They are indicated by starting the comment with:
// for a single-line comment
/** typing the multi-line comment ... ... and ending it with */
White space is also sometimes referred to as negative space and is the space between the characters of text that make up the lines of your source code text file. For example a space, tab or enter/break are all referred to as white space. Processing unlike other programming languages (such as Python) completely ignore white space, just like it ignores comments. Programming languages that ignore white space and allow the programmer to decide how to format their own code are known as free form languages. However, just because Processing ignores white space doesn't mean you should, as using consistent spacing and formatting within your code can make it easier to read. For example:
Although the above code is valid the same program rewritten with proper formatting can be easier to read (especially when you are in a rush or just glazing over it), for example:
You can probably imagine how unreadable code could quickly become when creating more complex programs with hundreds of statements. Let's revisit our Hello World 1.0 program and retype it taking standardized coding practices into consideration.
println("Hello World"); size(640,480);
/** * Hello World 1.0 Program * by Lyndon Daniels. * 11/01/2011 * This example program demonstrates how to * create a Hello World Program in Processing. */ //Determine the size of the Display window size(640,480); //Print characters to the console println("Hello World");
Program NotesFirstly you'll notice that every line in the documentation comment except the first and last lines of this comment start with an asterisk “*”. This is not necessary but, it does make the code look somewhat “nicer” and many programmers adopt this fashion of multi-line commenting so I've included it in this program. To Processing such niceties make absolutely no difference, but to us it makes the code a little easier to read.
It is standardized coding practice to include the following information in the documentation comment.
Name of the program,
The programmers name,
The date on which the program was released,
A brief description of what the program does.
Secondly it's worth noting that the order in which the statements are executed (or run) has changed. Code written in this way resembles a procedural programming style meaning that the code is executed one line after the next starting at the top of the document and working down. As a result it makes more sense to define the size of the Display Window before any other code is run. Although in this sketch using this particular order for the two statements is not entirely necessary, it is still a standard practice amongst many Processing programmers to include the size() function at the beginning of a program and not at the end. This is also a more logical approach to writing code in terms of how programs are structured within Processing. At a later stage you will see that when using the setup() function starting with the size() function, before any other functions following setup(), is mandatory.