Physics 5640: Computational Physics II

C style guide
Here are some guidelines about the few style issues I consider important for this course.
The most important is to have your programs follow some consistent indentation convention,
Indentation
If statements: If the body of an if statement (the code that gets executed if the condition
is met) is not on the same line as the if itself, then indent it relative to the other text,
so that one can see at a glance where the body ends (i.e. where execution continues if the
condition is not met). The same goes for the else clause of an if statement. Dont indent
the else, but do indent the body of the else if its not on the same line. For example,
some statement;
if (x > 3) {
an indented statement;
an indented statement;
an indented statement;
}
else {
an indented statement;
an indented statement;
an indented statement;
}
some statement;
some statement;
if (x > 4) y = x+3; /* this one fit on the same line as the if */
some statement;
some statement;
if (x > 5) {
an indented statement;
an indented statement;
if (y < 3) {
a doubly indented statement;
a doubly indented statement;
}
else {
a doubly indented statement;
a doubly indented statement;
}
an indented statement;
an indented statement;
}
1
else
an indented statement;
an indented statement;
}
some statement;
some statement;
Use enough of an indentation so that the structure is easily visible. (One space is not enough.
Two is probably okay.) Note above that the bodies of if statements that are embedded inside
other if statements are doubly indented (and further nesting would lead to triple indents,
etc.).
Loops: The body of a loop (for, while, do) unless the entire loop ts on one line. For
example,
some statment;
some statment;
for (i=0; i<n; i++) {
an indented statement;
an indented statement;
an indented statement;
}
some statment;
for (m=0; m<WeeWeeTimes; m++) printf(Wee, wee, wee\n);
some statment;
for (i=0; i<n; i++) {
for (j=0; j<n; j++) {
a doubly indented statement;
a doubly indented statement;
if (i < j) {
a triply indented statement;
a triply indented statement;
a triply indented statement;
}
else {
a triply indented statement;
a triply indented statement;
}
}
an indented statement;
an indented statement;
}
some statment;
some statment;
Subroutine/function bodies: Generally, one also indents the bodies of subroutine deni-
tions.
2
void PrintWeeWee(int WeeWeeTimes) {
int m;
for (m=0; m<WeeWeeTimes; m++) printf(Wee, wee, wee\n);
}
Positioning of Curly Braces
Dierent people have dierent conventions about what to do with the curly braces that
surround the bodies of if statements, loops, etc. In the example above, I showed the one I
tend to use. Other people like to have the open and close curly braces line up vertically, so
they put the open brace on a separate line as follows:
some statment;
some statment;
for (i=0; i<n; i++)
{
an indented statement;
an indented statement;
an indented statement;
}
some statment;
for (m=0; m<WeeWeeTimes; m++) printf(Wee, wee, wee\n);
some statment;
for (i=0; i<n; i++)
{
for (j=0; j<n; j++)
{
a doubly indented statement;
a doubly indented statement;
if (i < j)
{
a triply indented statement;
a triply indented statement;
a triply indented statement;
}
else
{
a triply indented statement;
a triply indented statement;
}
}
an indented statement;
an indented statement;
}
some statment;
some statment;
3
Other people do this, but they indent the curly braces as well as further indenting the body
of the paragraph:
for (i=0; i<n; i++)
{
for (j=0; j<n; j++)
{
a doubly indented statement;
a doubly indented statement;
if (i < j)
{
a triply indented statement;
a triply indented statement;
a triply indented statement;
}
else
{
a triply indented statement;
a triply indented statement;
}
}
}
Personally, I dont like this last version because you can quickly get indented so far that you
run out of room on the right and have trouble tting your individual statements on a single
line. However, you can use any convention you like, as long as it is clear and obeys the basic
principle that the bodies of conditional statements, loops, and subroutines are indented.
Long Lines
If a single line of code is so long that it gets truncated or wrapped when you print out
your program, then split the line up so that it doesnt. Trying to follow the ow of code
when lines are wrapped around in the print-out is almost as bad as trying to follow the code
of someone who doesnt bother to indent their code consistently. Remember that in C and
C++, a single statement does not need to t on a single line of code. So, for example,
BigFrogJump = BigFrogScalingFactor(BestFrog) * CanonicalFrogJump
+ BigFrogFudgeFactor;
instead of a single line that prints out as
BigFrogJump = BigFrogScalingFactor(BestFrog) * CanonicalFrogJump + BigFro
gFudgeFactor;
or (even worse)
BigFrogJump = BigFrogScalingFactor(BestFrog) * CanonicalFrogJump + BigFro
4
Long Bodies
You should generally try hard to avoid very long bodies of nested statements or loops
bodies that are so long that you can no longer easily tell visually which structure a given
} terminates. The way you avoid it is by thinking how to divide your code up into logical
units that can be handled by dening subroutines. However, every once in a while trying
to make a long section of code shorter in this way is less clear than just writing the whole
thing out in one go. When that happens, it is sometimes useful to put a comment after a
} explaining what it terminates. (Caution: This is distracting for bodies that are short
enough that its already visually obvious. So do not do this as a general rule. Reserve it for
cases where its really confusing otherwise.) For example,
for (i=0; i<n; i++) {
for (j=0; j<n; j++) {
... many, many, many lines ...
if (i < j) {
.. many, many, many lines ...
}
else {
/* here i >= j*/
... many, many, many lines ...
} /* if i < j else */
... many, many, many lines ...
} /* for j */
} /* for i */
Constants
Heres another, unrelated style issue. If you are going to use some constant number in
a programthe error tolerance you want to achieve in nding a result, the number of sub-
intervals to use in numerical integration, whateverit is usually a good idea to give that
constant a name rather than build it directly into the program. So, instead of
if ( fabs(CurrentEstimate - PreviousEstimate) < 0.001 )
write
const double ErrorGoal = 0.001; /* absolute error goal */
...
if ( fabs(CurrentEstimate - PreviousEstimate) < ErrorGoal )
Similarly, if we subdivide [2.5,5.0] into ten intervals, and loop through them, letting x be the
left end point of each interval, dont write
for (interval=0; interval<10; interval++) {
x = 2.5 + 0.35*interval
...
}
5
Instead write
const double xmin = 2.5; /* left end of region */
const double xmax = 3.5; /* right end of region */
const int Nintervals = 10; /* number of intervals to use */
...
for (interval=0; interval<Nintervals; interval++) {
x = xmin + interval*(xmax-xmin)/Nintervals;
...
}
There are three advantages. One is that the code is more readable and understandable
to other people (like me when I grade it). The second is that it is more readable and
understandable to you, when you realize two weeks to ve years later that you want to
modify it for something else and can no longer remember exactly how it worked. The
third is that if you later change it to use 20 intervals, you might change interval<10 to
interval<20 and forget that you then also need to change 0.35interval to 0.175interval. In
the later version, you would never make this mistake. Youd just change Nintervals=10 to
Nintervals=20, and everything would take care of itself.
6