Introduction to Computational Thinking (Fall 2025) Elements of Programming Style

Dear students,

Although we do not require one particular "correct" programming
style, we do want you follow a few basic style guidelines. Remember
that your programs must not just *work* (correctly), they must also be
understandable (and even pleasant) to read.

* Get your indentation right and line up the indentation of
beginning and ending brackets around blocks of code. It actually
doesn't matter too much exactly what style you adopt for your
indentation or placement of brackets around code blocks, but it should
make it easy to read the code and you must be *consistent throughout
all your programs*. If you are using an IDE, e.g., Eclipse, follow its
default style.

* Use blank lines to denote structure and increase readability. Just
as we use paragraphs to denote writing structure, use a blank line
between two bunches of statements; or between the declarations of
variables and the rest of the statements of the method. Also, leave
one blank line before the definitionf of the next method.

* Keep your lines of code less than 80 characters long. If you're
using Windows this might be easy to forget, but traditionally, when
programs are printed out or viewed in editors such as those on the
Pantheon, lines with more than 80 characters tend to wrap around,
messing up the indentation and making it hard to read.

* Comment wisely. At the top of each method, put a comment
summarizing what the method does, how it works, and what parameters it
expects. Within each method, comment major or critical blocks of
code. Do not, however, over-comment by writing an essay when a single
line of code is clear enough to understand already.

* Use descriptive names for variables and methods; for example use
descriptive names like "checkNumber" and "owedAmount" instead of "A"
and "B". Single letter variable or method names are discouraged,
unless the variable is a loop variable, temporary variable (used to
swap the values of two others), or has a very clear meaning." DO NOT
use all capital letters for names of variables--use them only for
constants.

* To decide whether a method is too long and whether it should be
broken down into two or more methods, a common rule of thumb is that
the method should not be longer than one or two screens of text (i.e.,
about 50 lines). If your method is much longer than that, chances are
you're trying to take care of too much functionality in a single
method. Try breaking it down into smaller pieces, each which
accomplishes a simpler part of solving the problem.

* Remove redundancy. Many programming structures (methods,
variables) are introduced to remove redundancy. Redundancy often leads
to inconsistency, and hence try to eliminate redundancy whenever you
can.

* Don't overuse global (class) variables. In particular, using
global variables as a convenient way of passing values around to
multiple methods may lead to strong coupling among the methods and the
global variables. For example, if you want to rename a global
variable, you will need to find all of the methods using that variable
and fix them. Good, reusable design avoids such coupling, whenever
possible.

* Don't overuse arrays after we introduce arrays. Arrays are great
for some purposes, but trying to solve every problem using them can
lead to contorted and long solutions.

Assignments are not meant to kill you. If you are spending more than
10 hours on trying to figure something out, then that's really kind of
too much; so ask the instructor or the TFs.

--- The ICT team (Oct. 15, 2025)