|
|
|
|
Chapter: Hello
World Program 1.0
Standardized
Coding
Practices
Standardized 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
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:
// for a single-line comment
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:
/** typing the multi-line comment
...
...
and ending it with */
White Space
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:
println("Hello World");size(640,480);
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:
println("Hello World");
size(640,480);
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.
/**
* 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 Notes
Firstly 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.
|
|
|
|
|
|
Previous
