Programming: Plan First, Then Code

Many novice programmers attempt to dive right into writing the code (in the
programming language) as the first step. However, writing the code is actually a much
later step in the process. A good programmer will plan first and write second, possibly
breaking down a large programming task into several smaller tasks in the process. Even
when cautioned to plan first and code second, many programming students ignore the
advice—after all, why “waste” 30 minutes planning when you are time-crunched from all
the work you have to do. This tradeoff, however, presents a false economy—30 minutes
planning could save hours of trying to make the code work properly. Well planned code
is not only more likely to be correct (or at least closer to correct), but is also easier to
understand—and thus fix.

To try to better understand the importance of planning before you write, imagine an
analogy to building a house or sky scraper. If you were tasked with building a sky
scraper, would you break ground and start building right away, figuring out how the
building is designed as you go? Hopefully not. Instead, you (or an architect) would
design blueprints for the building first. These blueprints would be iteratively refined until
they meet everyone’s specifications—they must meet the requirements of the building’s
owner, as well as be possible to build reasonably. Once the blueprints are completed,
they must be approved by the local government. Actual construction only begins once
the plans are fully completed. Programming should be done in a similar manner— come
up with a complete plan (algorithm) first and build (implement in code) second.

We said that the heart of programming is to figure out how to solve a class of problems
—not just one particular problem. The distinction here is best explained by an example.
Consider the task of figuring out if a particular number (e.g., 7) is prime. With sufficient
knowledge of math (i.e., the definition of a prime number and the rules of division), one
can solve this problem—determining that 7 is in fact prime. However, a programming
problem typically looks at a more general class of problems. We would typically not
write a program to determine if 7 is prime, but rather a program which, given a number
N, determines if N is prime. Once we have an algorithm for this general class of
problems, we can have the computer solve any particular instance of the problem for
us.

When we examine a class of problems, we have parameters which tell us which

particular problem in the class we are solving. In the previous example, the class of
problems is parameterized by N—the number we want to test for primality. To develop
an algorithm for this class of problems, we must account for all possible legal values of
the parameters. As we will see later, programming languages let us restrict what type of
information a parameter can represent, to limit the legal values to those which make
sense in the context of the problem. For primality testing, we would want our parameter
N to be restricted such that it can only hold integer numbers. It would not make any
sense to check if letters, words, or files are prime.
To write a program which takes any number N and determines if N is prime, we must
first figure out the algorithm for this class of problems. As we said before, if we attack
the problem by blindly writing code, we will end up with a mess—much like constructing
a sky scraper with no plan. Coming up with the appropriate algorithm for a class of
problems is a challenging task, and typically requires significant work and thought.

Overview of the Seven Steps

The Seven Steps

This figure shows a high-level overview of the programming process. A programmer

starts by devising the algorithm for the task she is trying to solve. We will split this
planning phase into four steps in the process of writing a program, which we will discuss
in more detail shortly. At the end of these four steps, the programmer should have a
complete plan for the task at hand—and be convinced that the plan is a good one.

After devising a proper algorithm, she is ready for Step 5 of the programming process:
translating her plan into code in the programming language she is using for her current
project. Initially, translation to code will go slowly, as you will be unfamiliar with the
syntax, likely needing to look up the specific details often. However, even if slow, it
should be fairly straightforward. You already devised the plan, so you should have done
all the actual problem-solving tasks already. Your algorithm may have some complex
steps, but that is fine. As we will see later, whenever your algorithm calls for a step that
is too complicated to be simply translated into a few lines of code, you should turn that
step into its own separate programming task and repeat the programming process on it.
In the next course, we will discuss translation to code in much more detail, as well as
how to turn the code into something that the computer can run.

Once the algorithm is implemented in code, the programmer must test her code, which
is the 6th Step of the programming process. By testing the program, the programmer
tries to uncover errors in her algorithm or implementation. If the programmer finds errors
in her program, she debugs the program (Step 7): finding out the cause of the error, and
fixing it. The programmer may need to return to the algorithm design steps (if the error
lies in the algorithm) or to translation to code (if the error lies in the implementation) to
correct the error. The programmer then repeats all of the later steps.

At some point, the programmer completes enough test cases with no errors to become
convinced that her program is correct. Note that we said the programmer becomes
convinced that her program is correct. No amount of testing can guarantee that the
program is correct. Instead, more testing increases the programmer's confidence that
the code is correct. When the programmer is convinced her code is correct, she has
successfully completed the task at hand. We will discuss testing and debugging in much
more detail in the next course.

Algorithms

Algorithms
As we discussed earlier, an algorithm is a clear set of steps to solve any problem in a
particular class. Typically, algorithms have at least one parameter; however, algorithms
with no parameters exist—they are simply restricted to one specific problem, rather than
a more general class. We can discuss and think about algorithms in the absence of any
particular knowledge of computers—a good algorithm can not only be translated into
code, but could also be executed by a person with no particular knowledge of the
problem at hand.

Algorithms that computers work on deal with numbers—in fact the module Types will
discuss the concept of "Everything is a number," which is a key principle in
programming. Computers can only compute on numbers; however, this course will also
illustrate how we can represent a variety of useful things (letters, words, images, videos,
sound, etc.) as numbers so that computers can compute on them. As a simple
example of an algorithm that works with numbers, we might consider the following
algorithm (which takes one parameter N, a non-negative integer):

For any non-negative integer N that I give you, you should be able to execute these
steps. If you do these steps for N = 2, you should come up with the sequence of
numbers 0 4 12 10. These steps are unambiguous as to what should happen. It is
possible that you get the wrong answer if you misunderstand the directions, or make
arithmetic mistakes, but otherwise, everyone who does them for a particular value of N
should get the same answer. We will also note that this algorithm can be converted into
any programming language quite easily—all that is needed is to know the basic syntax
of the particular language you want.

You may wonder why we would want an algorithm that generates this particular
sequence of numbers. In this case, it is just a contrived algorithm to show as a simple
introductory example. In reality, we are going to devise algorithms that solve some
particular problem. However, devising the algorithm for a problem takes some
significant work, and will be the focus of discussion for the rest of this module.

Even though computers can only work with numbers, we can envision algorithms that
might be executed by humans who can work on a variety of things. For example, we
might write algorithms that operate on physical objects such as LEGO bricks or food.
Even though such things would be difficult to implement on a computer (we would need
the computer to control a robot to actually interact with the physical world), they are still
instructive, as the fundamental algorithmic design principles are the same.

One exercise done at the start of some introductory programming courses is to have the
students write down directions to make a peanut butter and jelly sandwich. The
instructor then executes the algorithms, which are often imprecise and ambiguous. The
instructor takes the most comical interpretation of the instructions to underscore that
what the students wrote did not actually describe what they meant.

This exercise underscores an important point—you must specify exactly what you want
the computer to do. The computer does not "know what you mean" when you write
something vague, nor can it figure out an "etc." Instead, you must be able to describe
exactly what you want to do in a step-by-step fashion. Precisely describing the exact
steps to perform a specific task is somewhat tricky, as we are used to people implicitly
understanding details we omit. The computer will not do that for you (in any
programming language).

Even though the "sandwich algorithm" exercise makes an important point about
precisely describing the steps you want the computer to perform, it falls short in truly
illustrating the hardest part of designing an algorithm. This algorithm has no
parameters, so it just describes how to solve one particular problem (making a peanut
butter and jelly sandwich). Real programming problems (typically) involve algorithms
that take parameters. A more appropriate problem might be "Write an algorithm that
takes a list of things you want in a sandwich and describes how to make the sandwich."

Such a problem is much more complex but illustrates many concepts involved in
devising a real algorithm. First, our algorithm cannot take a list of just anything to
include in the sandwich—it really will only work with certain types of things, namely
food. We would not expect our algorithm to be able to make us a "car, skyscraper,
airplane" sandwich. These items are all the wrong type. We will learn more about types
in programming later in this course.
Our algorithm may also have to deal with error cases. Even if we specify the correct
type of inputs, the particular values may be impossible to operate on correctly. For
example, "chicken breast" is food, but if the chicken breast has not been cooked yet, we
should not try to make a sandwich out of it. Another error case in our sandwich creation
algorithm might be if we specify too much food to go inside the sandwich (how do you
make a sandwich with an entire turkey, 40 pounds of carrots, and 3 gallons of ice
cream?). Of course, if we were writing this sandwich algorithm for humans, we could
ignore this craziness because humans have "common sense"—however, computers do
not.

Even if we ignore all of the error cases, our general algorithm is not as simple as just
stacking up the ingredients on top of bread in the order they appear in the input. For
example, we might have an input of "chicken, mustard, spinach, tomatoes." Here, we
probably want to spread the mustard on the bread first, then place the other ingredients
on it (hopefully in an order that makes the most stable sandwich).

It would seem that writing a correct algorithm to make a sandwich from an arbitrary list
of ingredients is quite a complex task. Even if we did not want to implement that
algorithm in code, but rather have it be properly executed by a person with no common
sense (or a professor with a comedic disregard for common sense), this task is quite
challenging to do correctly. How could we go about this task and hope to get a good
algorithm?

The wrong way to write an algorithm is to just throw some stuff on the page, and then
try to straighten it out later. Imagine if we approached our sandwich example by writing
down some steps and having someone (with no common sense) try them out. After the
kitchen catches on fire, we try to go in and figure out what went wrong. We then tweak
the steps, and try again. This time, the kitchen explodes instead. We repeat this
process until we finally get something that resembles a sandwich, and the house did not
burn down.

The previous paragraph may sound silly, but is exactly how many novice (and
intermediate) programmers approach programming tasks. They jump right into writing
code (No time to plan! Busy schedule!), and it inevitably does not work. They then pour
countless hours into trying to fix the code, even though they do not have a clear plan for
what it is supposed to do. As they "fix" the code, it becomes a larger, more tangled
mess. Eventually, the program sort-of-kind-of works, and they call it good enough.
Instead, you should devise an algorithm in a disciplined fashion. The above figure
shows how you should approach designing your algorithm. We will spend the next few
sections discussing each of these steps in detail. However, note that "translate to code"
comes only after you have an algorithm that you have tested by hand—giving you some
confidence that your plan is solid before you build on it.

If you plan well enough and translate it correctly, your code will just work the first time.
If it does not work the first time, you at least have a solid plan of what the code should
be doing to guide your debugging.

Step 1: Work an Example Yourself

Step 1: Work an Example Yourself

The first step in trying to design an algorithm is to work at least one instance of the
problem—picking specific values for each parameter—yourself (by hand). Often this
step will involve drawing a diagram of the problem at hand, in order to work it precisely.
The more precisely you can perform this problem (including the more precisely you can
draw a diagram of the situation if applicable), the easier the remainder of our steps will
be. A good example of the sort of picture you might draw would be the diagrams drawn
in many science classes (especially physics classes). The figure shows multiple copies
of the box for this step layered one on top of the other, as you may need to perform this
step multiple times to generalize the algorithm properly.

One of the examples of an algorithm that we mentioned early in this chapter was
determining if a number is prime. If you were trying to write a function to determine if a
number is prime, your first step would be to pick a number and figure out if it is prime.
Just saying "ok, I know 7 is prime," is not of much use—you just used a fact you know
and did not actually work out the problem. For a problem such as this one, which has a
"yes or no" answer, we probably want to work at least one example that comes up with
a "yes" answer, and one that comes up with a "no" answer.

Another example would be if we wanted to write a program to compute x raised to the y

power. To do Step 1, we would pick particular values for x and y, and work them by
hand. We might try x = 3 and y = 4, getting an answer of 3^4 = 81.
If you get stuck at this step, it typically means one of two things. The first case is that
the problem is ill-specified—it is not clear what you are supposed to do. In such a
situation, you must resolve how the problem should be solved before proceeding. In the
case of a classroom setting, this resolution may require asking your professor or TA for
more details. In an industrial setting, asking your technical lead or customer may be
required. If you are solving a problem of your own creation, you may need to think
harder about what the right answers should be and refine your definition of the problem.

The second case where Step 1 is difficult is when you lack domain knowledge—the
knowledge of the particular field or discipline the problem deals with. In our primality
example, if you did not remember the definition of a prime number, that would be an
example of lacking domain knowledge—the problem domain is mathematics, and you
are lacking in math knowledge. No amount of programming expertise nor effort
("working harder") will overcome this lack of domain knowledge. Instead, you must
consult a source of domain expertise—a math textbook, website, or expert. Once you
have the correct domain knowledge, you can proceed with solving your instance of the
problem. Note that domain knowledge may come from domains other than math. It can
come from any field, as programming is useful for processing any sort of information.

Sometimes, domain knowledge may come from particular fields of computer science or
engineering. For example, if you intend to write a program that determines the meaning
of English text, the relevant domain field is actually a sub-field of computer science,
called Natural Language Processing. Here the domain knowledge would be the specific
techniques developed to write programs that deal with natural language. A source of
domain knowledge on English (an English professor or textbook) is unlikely to contain
such information.

Step 2: Write Down What You Just Did

Step 2: Write Down What You Just Did

For this step, you must think about what you did to solve the problem, and write down
the steps to solve that particular instance. Another way to think about this step, is to
write down a clear set of instructions that anyone else could follow to reproduce your
answer for the particular problem instance that you just solved. If you do multiple
instances in Step 1, you will repeat Step 2 multiple times as well, once for each instance
you did in Step 1. If an instruction is somewhat complex, that is all right, as long as the
instruction has a clear meaning—later, we will turn these complex steps into their own
programming problems, which will get solved separately.

The difficult part of Step 2 is thinking about exactly what you did to accomplish the
problem. The difficulty here is that it is very easy to mentally gloss over small details,
"easy" steps, or things that you do implicitly. This difficulty is best illustrated by the
peanut butter and jelly exercise we mentioned earlier. Implicit assumptions about what
to do, or relying on common sense lead to imprecise or omitted steps. The computer
will not fill in any steps you omit, thus you must be careful to think through all the details.

Returning to our example of computing x to the y, we might write down the following
steps for x = 3 and y = 4:

The steps are very precise—and leave nothing to guess work. Anyone who can
perform basic arithmetic can follow these steps to get the right answer. Computers are
very good at arithmetic, so none of these steps is even complex enough to require
splitting into a sub-problem.

Step 3: Generalize Your Steps

Step 3: Generalize Your Steps

Having solved one or more problems from the class we are interested in and written
down the particular steps we executed to solve them, we are ready to try to generalize
those steps into an algorithm. In our Step 2 steps, we solve particular instances, but
now we need to find the pattern that allows us to solve the whole class. This
generalization typically requires two activities. First, we must take particular values that
we used and replace them with mathematical expressions of the parameters. Looking
at our Step 2 steps for computing 3^4, we would see that we are always multiplying 3
by something in each step. In the more general case, we will not always use 3—we are
using 3 specifically because it is the value that we picked for x. We can generalize this
slightly by replacing this occurrence of 3 with x:
The second common way to generalize steps is to find repetition—the same step
repeated over and over. Often the number of times that the pattern repeats will depend
on the parameters. We must generalize how many times to do the steps, as well as
what the steps are. Sometimes, we may find steps which are almost repetitive, in which
case we may need to adjust our steps to make them exactly repetitive. In our 3^4
example, our multiplication steps are almost repetitive—both multiply x by "something,"
but that "something" changes (3 then 9 then 27). Examining the steps in more detail,
we will see that the "something" we multiply is the answer from the previous step. We
can then give it a name (and an initial value) to make all of these steps the same:

Now, we have the same exact step repeated three times. We can now contemplate
how many times this step repeats as a function of x and/or y. We must be careful not
to jump to the conclusion that it repeats x times because x = 3—that is just a
coincidence in this case. In this case, it repeats y - 1 times. The reason for this is that
we need to multiply 4*3s together, and we already have one in n at the start, so we
need y - 1 more. This would lead to the following generalized steps:

We need to make one more generalization of a specific value to a function of the

parameters. We start with n = 3; however, we would not always want to start with 3.
In the general case, we would want to start with n = x:

Sometimes you may find it difficult to see the pattern, making it hard to generalize the
steps. When this happens, returning to Steps 1 and 2 may help. Doing more instances
of the problem will provide more information for you to consider, possibly giving you
insight into the patterns of your algorithm. This process is often referred to as writing
'pseudo-code', as you are working to design an algorithm programmatically with no
particular target language. Nearly all programmers make use of this method to ensure
their algorithm is correct before writing any actual code.

Step 4: Test Your Algorithm

Step 4: Test Your Algorithm
After Step 3, we have an algorithm that we think is right. However, it is entirely possible
that we have messed up along the way. The primary purpose of Step 4 is to ensure our
steps are actually right before we proceed. To accomplish this, we test our algorithm
with different values of the parameters than the ones we used to design our algorithm.
We execute our algorithm by hand and compare the answer it obtains to the right
answer. If they differ, then we know our algorithm is wrong. The more test cases
(values of parameters) we use, the more confident we can become that our algorithm is
correct. Unfortunately, it is impossible to ensure that our algorithm is correct by testing.
The only way to be completely sure that your algorithm is correct is to formally prove its
correctness (using a mathematical proof), which is beyond the scope of this
specialization.

One common type of mistake is mis-generalizing in Step 3. As we just discussed, one

might think that the steps repeated x times because x = 3 and the steps repeated 3
times. If we had written that down in Step 3, our algorithm would only work when x = y
– 1; otherwise we would count the wrong number of times and get the wrong answer. If
that were the case, we would hopefully detect the problem by testing our algorithm by
hand in Step 4. When we detect such a problem, we must go back and re-examine the
generalizations we made in Step 3. Often, this is best accomplished by returning to
Steps 1 and 2 for whatever test case exposed the problem. Re-doing Steps 1 and 2 will
give you a concrete set of steps to generalize differently. You can then find where the
generalization you came up with before is wrong, and revise it accordingly.

Another common type of mistake is that there are cases we did not consider in
designing our algorithm. In fact, in our x^y example, we did not consider what
happens when y = 0, and our algorithm handles this case incorrectly. If you execute
the algorithm by hand with x = 2, y = 0, you should get 2^0=1; however, you will get
an answer of 2. Specifically, you will start with n = x = 2. We would then try to count up
from 1 to 0 – 1 = –1, of which there are no numbers, so we would be done counting
right away. We would then give back n (which is 2) as our answer.

To fix our algorithm, we would go back and revisit Steps 1 and 2 for the case that failed
(x = 2, y = 0). This case is a bit tricky since we just know that the answer is 1 without
doing any work (x^0=1 for any x). The fact that the answer requires no work makes
Step 2 a little different—we just give an answer of 1. While this simplicity may seem
nice, it actually makes it a little more difficult to incorporate it into our generalized steps.
We might be tempted to write generalized steps like these:
These steps check explicitly for the case that gave us a problem (y = 0), give the right
answer for that case, then perform the more general algorithm. For some problems,
there may be corner cases which require this sort of special attention. However, for this
problem, we can do better. Note that if you were unable to see the better solution and
were to take the above approach, it is not wrong per se, but it is not the best solution.

Instead, a better approach would be to realize that if we count no times, we need an

answer of 1, so we should start n at 1 instead of at x. In doing so, we need to count 1
more time (to y instead of to y – 1)—to multiply by x one more time:

Whenever we detect problems with our algorithm in Step 4, we typically want to return
to Steps 1 and 2 to get more information to generalize from. Sometimes, we may see
the problem right away (e.g., if we made a trivial arithmetic mistake, or if executing the
problematic test case by hand gives us insight into the correct generalization). If we see
how to fix the problem, it is fine to fix it right away without redoing Steps 1 and 2, but if
you are stuck, you should redo those steps until you find a solution. Whatever approach
you take to fixing your algorithm, you should re-test it with all the test cases you have
already used, as well as some new ones.

Determining good test cases is an important skill that improves with practice. For
testing in Step 4, you will want to test with cases which at least produce a few different
answers (e.g., if your algorithm has a "yes" or "no" answer, you should test with
parameters which produce both "yes" and "no"). You should also test any corner cases
—cases where the behavior may be different from the more general cases. Whenever
you have conditional decisions (including limits on where to count), you should test
potential corner cases right around the boundaries of these conditions. For example, if
your algorithm makes a decision based on whether or not x < 3 , you might want to test
with x = 2, x = 3, and x = 4. You can limit your "pencil and paper" testing somewhat,
since you will do more testing on the actual code once you have written it.

Examples

A Pattern of Squares
For our second example, we will look at a pattern of squares drawn on a grid. You may
wonder why a programmer would be interested in drawing squares on a grid. Beyond
this example serving us well for analyzing patterns in general, computer graphics
ultimately boil down to drawing colored pixels on a 2D grid (the screen). In this
particular example, we have an algorithm that is parameterized over one integer N and
produces a pattern of red and blue squares on a grid that starts all white. The output of
the algorithm for N = 0 to N = 5 is as follows:

To devise the algorithm, we should work through steps 1–4 (as we should with all
problems). The next video walks through these steps to illustrate how we could come
up with this algorithm.

We note that there are many correct algorithms for this problem. Even if we restrict
ourselves to the ones we can come up with naturally (that is, as a result of working
through steps 1–4, rather than trying something bizarre), there are still many choices
that are equivalent and correct. Which algorithm you come up with would be determined
by how you approach step 1.

The algorithm in the video works from left to right, filling in each column from bottom to
top. If we had worked step 1 by working from the top down, filling in each row from left
to right, we might have ended up with the following slightly different algorithm instead:
Of course, those are not the only two ways. You could have worked across the rows
from the bottom up going right to left, and come up with a slightly different (but also
equivalent) algorithm. Or even an entirely different approach, such as filling in the entire
"triangle" with red squares, then going back to fill in the blue squares.

We emphasize this point because it is important for you to understand that there is
always more than one right answer to a programming problem. You might work a
problem and come up with a correct solution but find that it looks completely different
from some other solution you know to be correct (e.g., the ones provided for some of
the problems in this book, or a teacher's solutions to an exam). Understanding this
possibility is important so that you will not incorrectly think that a right answer is wrong
because you have seen a different right answer. Not only is that experience frustrating,
but it hinders your learning.

Declaring a Variable

Variables
Programs track most of their state in variables—you can think of a variable as a box that
stores a value. In order to use a variable, the programmer must declare it, specifying its
type and name. The type specifies what kind of value can be held in a variable's box
(for example, whether it is a number, a letter, or text). We will learn about types in the
next module, but for now, we will use variables whose types are all int—meaning that
the value in their box is a number.

Declaration
The name of a variable may be any valid identifier. An identifier is the formal
programming term for a word that can be used to name something. In C, identifiers may
be any length, and can contain letters, numbers, and underscores (_). They may only
start with a letter or an underscore (not a number), and are case-sensitive (meaning that
abc is different from Abc and ABC is different from both of them). The variable
declaration ends with a semicolon—which is used to end many statements in C. A
statement in a programming language is roughly analogous to a sentence in English—it
is a complete line of code, which can be executed for an effect. This figure shows a
variable declaration and identifies each of the pieces:
When executing code by hand, the effect of a variable declaration is to create a new
box, labeled with the name of the variable. In C, a newly declared variable is
uninitialized, meaning that its value is undefined. When the computer actually executes
the program, it has a finite (but quite large) number of "boxes" (memory locations), and
the variable will be given one that is currently not in use. The value of the variable will
be whatever value happened to be in the location previously, until a new value is
assigned to the variable (which we will see shortly). Correspondingly, when we execute
a variable declaration by hand, we will draw a box and place a (?) in it for its value—
indicating that it is unknown. If we ever use an unknown value as we execute our
program, it indicates a problem with our program, since its behavior is undefined—its
behavior will be changed based on whatever the value actually is, which we cannot
predict.

The next video shows the execution of code containing two variable declarations—x
and y. At the start, the execution arrow is at the beginning of the code. The area on the
right—which represents the state of the program—is empty. As the execution arrow
advances across these statements, we execute their effects: drawing a box for each
variable, with a (?) in it, indicating that the variable is uninitialized.

Assigning a Variable
For variables to be useful, we must be able to change their values. To accomplish this,
we use assignment statements—statements which change the value contained in a
box. An assignment statement starts with an lvalue on the left. An lvalue (pronounced
“el-value”) must be something that “names a box”—indicating which box the assignment
statement will change. The simplest lvalue is a variable, which names the variable’s
own box. (Later we shall see how to name boxes in other ways, but for now, we will only
consider variable names.) After the lvalue, comes a single equals sign (called the
assignment operator), followed by an rvalue on the right, then a semicolon. The rvalue
(pronounced “are-value”) must be an expression whose value shall be placed in the
box.

An assignment statement
An expression is a combination of values, and operations which evaluates to a value.
For the moment, we will just consider numeric constants (such as 3), which evaluate
simply to themselves (that is, 3 evaluates to the number 3). We will discuss more
expressions shortly. Evaluating any assignment statement is a matter of figuring out
what box the left side names, evaluating the right side to a value (e.g., a number), and
then changing the value in the box named on the left side to the value from the right
side.

The figure below shows an example of an assignment statement, and identifies the
individual pieces. This assignment statement assigns the value 3 to the variable
myVariable. Its effect is to change the value in the box named myVariable to be 3.

Declarations and Assignments

The declaration and initialization—the first assignment—of a variable may be combined
into a single statement, such as int x = 3; which has the same effect as the two
individual statements int x; x = 3;. The next video shows the execution of a combination
of variable declarations and assignment statements.

Expressions with Common Operators

Expressions
As we mentioned previously, an expression is a combination of values and operations
which evaluates to a value. We have already seen the simplest expressions—numerical
constants, which evaluate to themselves. We can also use mathematical operators,
such as +, –, *, and / to carry out arithmetic operations. For example, 7 + 3 evaluates to
10 and 4 * 6 + 9 * 3 evaluates to 51. These operators have the standard rules of
precedence—multiplication and division occur before addition and subtraction—and
associativity: 4 – 3 – 1 means (4 – 3) – 1 not 4 – (3 –1). Parenthesis may be used to
enforce a specific order of operations—4 * (6 + 9) * 3 evaluates to 180.

Another common operator which you may not be as familiar with is the modulus
operator, %. The modulus operator evaluates to the remainder when dividing the first
operand by the second. That is a % b (read “a modulus b”, or “a mod b” for short) is the
remainder when a is divided by b. For example, 19 % 5 = 4 because 19 / 5 = 3 with a
remainder of 4—3 * 5 = 15, and 19 – 15 = 4.
One slightly tricky thing about division with integers is that dividing an integer by an
integer gives an integer. This means that 5 / 2 is 2. Note that we are using floor division
(ie: we round down the result). This happens because integer can only hold whole
numbers. In a later lesson you will learn about other types that can hold numbers like
2.5, so that you can compute with fractional numbers if you need to.

Variables may also appear in expressions. When a variable appears in an expression, it

is evaluated to a value by reading the current value out of its box. It is important to note
that assignment statements involving variables on the right side are not algebraic
equations to be solved—we cannot write x – y = z * q. Note that here, the left side of this
statement does not “name a box”. If you want to solve an algebraic equation, you must
do so in a step-by-step fashion.

We can, however, write perfectly meaningful assignment statements which are not valid
in algebra. For example, a statement such as x = x + 1; is quite common in
programming, but has no solution if you think of it as an algebraic equation. In
programming, this statement means to take current value of x, add 1 to it, and update
x’s value to whatever that result is.

The next video shows the execution of some assignment statements with more complex
expressions on their right-hand sides than in previous examples.

Anatomy of a Function

Functions
A function gives a name to a parameterized computation—it is the implementation in
code of a specific algorithm. All of the code that you will read or write (in this book) will
be inside of functions. There are two sides to using functions in your programming:
declaring a function—which provides the definition for how a function behaves—and
calling a function—which executes the definition of the function on specific values of the
parameters.
The figure above shows a function declaration. The function's name may be any valid
identifier, just like a variable's name. In this particular example, the function's name is
myFunction. Immediately before the function's name is its return type—the type of value
that this function will compute. As mentioned earlier, we will learn more about types
later. For now, we will just work with ints, which are numbers. The fact that this function
returns an int means that its "answer" is an int. After the function's name comes a set of
parentheses, with the parameter list inside. The parameter list looks like a comma-
separated list of variable declarations. Here, the function takes two parameters, x and y,
both of which are ints. The similarity between parameters and variable declarations is
not a coincidence—the parameters behave much like variables, but they are initialized
by the function call (which we will discuss shortly).

The body of the function then comes between a set of curly braces, and is comprised of
zero or more statements. The body of this function has two statements. The first
statement in this function's body is the now-familiar declaration and initialization of a
variable: z is declared as a variable of type int and initialized to the value of the
expression x – 2 * y.

The second statement within the body of this function is a new type of statement which
we have not seen before: a return statement. A return statement starts with the keyword
return, which is then followed by an expression. The effect of this statement is to say
what the "answer" is for the current function, leaving its computation and returning to the
code that called it.

To understand this last concept completely, we must first see the other aspect of using
a function—calling the function. A function is another kind of expression, whose value is
whatever "answer" the called function comes up with when it is executed with the
specified arguments—values of its parameters. This "answer" is more formally called
the function's return value.

How to Evaluate a Function

How to Evaluate a Function

Evaluating a function call is more complex than evaluating the other kinds of
expressions that we have seen so far—it may take many steps of executing the code in
the function to determine its answer. In fact, code may call one function, which itself
may call other functions before finally coming up with an answer. While this may seem
daunting, we can do it properly by following a few rules for executing function calls by
hand.

As a first step towards reading code with function calls, we must first group together the
variables belonging to one particular function into a larger box, labeled with the
function’s name, which is called a frame (or stack frame, since they are located on the
call stack). This figure shows an example of this organization.

Notice that in the example shown in the figure, one of the functions is named main. The
function named main is special—execution of a program starts at the start of main. We
start by drawing an empty frame for main and putting the execution arrow right before
the first line of code in main. We then execute statements of the code until main returns,
which ends the program.

Calls to functions may appear in expressions, in which case we must evaluate the
function to determine its return result. To do this evaluation, we take the following steps:

1. Draw a frame for the function being called. Place a box in that frame for
each parameter that this function takes.
2. Initialize the parameters by evaluating the corresponding expressions in the
function call and copying the resulting values into the parameter’s box in the
called function’s frame.
3. Mark the location of the function call, and note that location in the corner of
the function’s frame.
4. Move the execution arrow immediately before the first line of code in the
called function.
5. Evaluate the lines of code inside the called function.
6. When you reach a return statement, evaluate its argument to a value. Note
down this return value.
7. Return the execution arrow back to where the function was called—you
know this location because you noted it in the corner of the frame. You will
return the arrow to the middle of the line of code (rather than the typical
"between them") because that line of code is part-way done.
8. Erase the frame for the called function.
9. Use the return value of the function as the value of the function call in the
expression in which it appears.

A function call may also be used as a statement by itself, in which case, it is evaluated
the same as above, except that its return value is not used for anything.
The next video demonstrates the execution of code with function calls.

Scope

Scope
So far, all of our code examples have had only one variable with a particular name.
However, in real programs—which may be quite large and developed by multiple people
—we may have many different variables with the same name. This possibility means
that we need rules to determine which variable a particular name refers to. These rules
are based on the notion of scope.

The scope of a variable is the region of code in which it is visible. Within a variable’s
scope, its name may refer to it. Outside of a variable’s scope, nothing can refer to it
directly. Most variables that you will use will be local variables—variables that are
declared inside of a function—and function parameters. In C, the scope of a local
variable begins with its declaration and ends at the closing curly-brace (}), which closes
the block of code—the code between matching open and close curly braces—that the
variable was declared in. Function parameters have a scope of the entire function to
which they belong.

This figure shows a snippet of code (we have not learned the details of what most of
this code does, but that is not important—we are just interested in the scope of the
variables). The figure shows the same piece of code three times, with different scopes
highlighted. The leftmost portion of the figures shows the scope of the parameters (x
and y)—which is the entire function—in a blue box. The middle portion shows the scope
of the variable n—which starts at its declaration and continues to the close curly brace
which ends the function—in a red box. The right portion shows the scope of the variable
q—which starts at its declaration and ends at the next curly brace—in a green box.

To determine which variable a name refers to, we must first determine which variable(s)
with that name are in scope at the reference. If no variables of that name are in scope,
then the reference is illegal. If exactly one variable is in scope, then the name refers to
that variable. If multiple variables are in scope, we select the one whose declaration is
in the innermost enclosing block. That is, if you went backwards out of blocks, through
open curly braces, the variable which would go out of scope first is the one to use.

The figure below shows a code fragment with four different x's in it. (As the actual
behavior of the code is irrelevant to this example, much of it is replaced with [...]) The
first x in the figure is declared outside of any of the functions—it is a global variable. The
"box" for a global variable exists outside of any frames and is created when the program
starts. If the global variable is initialized in its declaration, the value is also placed in the
box before the program starts. The areas where x references this variable are colored
purple.

We note that there is a time and place to use global variables, but their use should be
rare. When novice programmers learn about global variables, they often want to use
them for all sorts of inappropriate purposes. Typically these uses reflect a lack of
understanding of parameter passing or how functions return values. We recommend
against using global variables for any problem in this specialization, and more generally
unless it is truly the correct design approach.
The next x in our example is the parameter to the function f. The scope for this x begins
at the open curly brace ({) of f’s body and ends at the matching close curly brace (}).
The region of the program where x references the parameter to f are shown in red.
Observe that the red begins and ends with the curly braces surrounding the body of f,
but has a "hole" where there is a different x in a smaller scope in the middle.

The "hole" in the red region corresponds to the portion of the code (shown in blue)
where x references the local variable declared inside of the while loop’s body. After this
local variable x goes out of scope at the closing curly brace of the block it was declared
in, we return to the red region, where the parameter of f is what we reference with the
name x.

Between the end of f and the declaration of a local variable named x inside of function
g, the global variable is what the name x references—shown in the figure by coloring
this region of code purple. When there is a local variable named x declared inside of g,
then the name x references it (this area is shown in green) until it goes out of scope, at
which point the name x again references the global variable.

If all of that seems complicated, you will be comforted by the fact that thinking through
such issues should not come up in well-written code. Ideally, you should write your code
such that you have at most one variable by any particular name in scope at a time
(related to this point: you should name your variables meaningfully—x is seldom a good
name for a variable, unless of course it represent the x-coordinate of a point or
something similar). However, you should still know what the rule is, as it is common to
many programming languages. You may come across code that has multiple variables
of the same name in scope at some point and need to understand how to read it.

Conditional Statements

Conditional Statements
In addition to computing arithmetic combinations of their variables, programs often
make decisions based on the values of their variables—executing different statements
based on the value of expressions. In C, an if/else statement specifies that one block of
code should be executed if a condition is true, and another block should be executed if
that condition is false.

To write meaningful if/else statements, we need to introduce operators which allow us to

compare two expressions and produce a Boolean outcome. In C, however, there are no
distinct values for true or false, instead, false is 0, and anything which is non-zero is
true. We will refer to true and false because they make more sense conceptually; the
distinction should not make a practical difference in most cases.
The table above shows the C operators for conditional expressions. The first six (==, !=,
<, <=, >, and >=) are relational operators—they compare two expressions for equality or
inequality. For any of these operators, both operands (the expressions on the left and
right) are evaluated to a value, then compared appropriately. The operator then
produces a true or false value.

The last three operators in the table (!, &&, and ||) are boolean operators—they operate
on true/false values. The first of these, ! performs the boolean NOT operation. It is a
unary operator—meaning that is has one operand—which evaluates to true if its
operand is false, and evaluates to false if its operand is true.

The && and || operators perform the logical AND and logical OR operations
respectively. The logical AND of two values is true if and only if both values are true,
otherwise it is false. The logical OR of two values is true if and only if either of the
values are true, otherwise it is false.

Unlike previous operators that we have seen, && and || may know their answer from
only one argument. In the case of &&, if either operand is false, then the result is false,
regardless of the other value. Similarly for ||, if either operand is true, then the result is
true regardless of the other value. C exploits this fact in the way that it evaluates && and
|| by making them short circuit—they may only evaluate one operand. Specifically, the
first operand is always evaluated to a value; however, if the value of that operand
determines the result of the entire && or ||—false for && or true for ||—then the second
operand is not evaluated at all.

if/else
Now that we understand comparison operators, and can compare expressions, we can
discuss the evaluation of if/else statements. The syntax for an if/else statement is
shown in figure below.
The keyword if is followed by an expression in parenthesis. This expression is evaluated
to a value, to determine whether the “then” block or the “else” block is executed. The
“then” block of code comes immediately after the expression. C does not have a then
keyword (although some languages do), however, this block of code serves the same
purpose regardless of the syntactic particulars of the language—it is executed if the
conditional expression evaluates to true. After the “then” block, we have the keyword
else, followed by the “else” block. This block of code is executed if the conditional
expression evaluates to false.

When your execution arrow reaches an if statement, evaluate the conditional

expression. Evaluating this expression proceeds just like evaluating any other
expression. If the result is true, move the execution arrow immediately inside the “then”
block and continue executing statements as usual. When your execution reaches the
close curly brace that ends the “then” block, skip over the else block, placing your
execution arrow immediately after the close curly brace of the “else” block, and continue
executing statements from there.

If the result of the conditional expression is false, you should instead skip the “then”
block and execute the “else” block. Move your execution arrow into the start of the
“else” block, and continue executing statements from there. When your execution arrow
reaches the close curly brace that ends the “else” block, simply move it past that curly
brace (which has no effect—it just denotes the end of the block) and continue executing
statements normally.

C permits if with no else, which is equivalent to an empty “else” block (as if the
programmer had written else {}). If you execute an if with no else, then simply imagine
the empty “else” block. If the conditional expression evaluates to true, you should
execute the “then” block as previously described, however, there is no “else” block to
skip. Instead, continue executing statements immediately after the end of the “then”
block (skipping over the non-existent “else” block). If the conditional expression
evaluates to false, then skip the “then” block, and execute whatever statements follow it
(doing nothing for the “else” block).

if/else statements may be nested—one (or more) may occur in the “then” or “else” block
of another if/else statement. When you encounter nested statements, the same rules
apply. The inner statement is just one of the (possibly) many statements in the block,
and is executed according to its rules—the condition is evaluated, whichever of the
“then” or “else” blocks is appropriate is executed, and then execution continues after the
end of the “else” block. When the execution arrow reaches the end of the outer “then” or
“else” block, it behaves no differently than if there were no inner if statement. The next
video demonstrates the execution of some if/else statements.

switch/case
Another way that programs can make decisions is to use switch/case. The syntax of
switch/case is shown in the figure below. Here, when the execution arrow reaches the
switch statement, the selection expression—in parenthesis after the keyword switch—is
evaluated to a value. This value is then used to determine which case to enter. The
execution arrow then jumps to the corresponding case—the one whose label (the
constant immediately after the keyword case) matches the selection expression’s value.
If no label matches, then the execution arrow jumps to the default case if there is one,
and to the closing curly brace of the switch if not.

Once the execution arrow has jumped into a particular case, execution continues as
normal until it encounters the keyword break. When the execution arrow reaches the
break keyword, it jumps to the close curly brace which ends the switch statement. Note
that reaching another case label does not end the current case. Unless the execution
arrow encounters break, execution continues from one statement to the next. When the
execution arrow passes from one case into the next like this, it is called “falling through”
into the next case.

For example, if we were executing the code in the figure above, and reached the switch
statement with x having a value of 17 and y having a value of 16, then we would first
evaluate the selection expression (x - y), and get a value of 1. The execution arrow
would then jump to case 1: and begin executing statements after it. We would execute y
= 9;. Then we would fall through the next case label—our execution arrow would move
past it into the next case (the label itself has no effect). Then we would execute z = 42;.
Next, we would execute the break; statement, causing our execution arrow to jump to
the close curly brace of the switch, after which we would continue executing whatever
other statements are there.
Shorthand
C (and many other programming languages) has shorthand—also called syntactic
sugar—for a variety of common operations. These shorthands do not introduce any new
behaviors. Instead, they just provide a shorter way to write common patterns of existing
things we have seen. This table shows the most common shorthand notations in C:

These shorthands have exactly the same effect as their expanded meanings.
Consequently, when you encounter a shorthand statement while executing code, you
can execute it by considering what its fully written out form is, and performing the effects
of that statement.

For the shorthands that combine an operation with assignment (such as *=), if the right
hand side involves other operation, you should treat the right hand side as
parenthesized when you expand the shorthand. That is

x *= y+3;

behaves just like

x = x * ( y +3);

This is because the intent is to multiply the left side (x) by the right side (y+3) and then
assign that to x.

Another possible shorthand is to omit the curly braces around single statement blocks of
code in certain cases. For example, if the “then” and/or “else” clause of an if statement
is one single statement, the curly braces are not required. While you may encounter
code written this way by other people, it is highly inadvisable to write code this way.
Omitting the curly braces presents a danger if you modify the code in the future. If you
add another statement to the clause, but forget to add curly braces, then the statement
will not actually be part of the clause, but rather the first statement after the if. Such
errors have produced high-profile security vulnerabilities recently.
Loops for Repetition

Loops for Repetition

Programs often repeat the same block of code multiple times, using a loop. As you may
recall from the examples in Module 1, algorithms often have repetitive behavior. Finding
repetitive patterns is crucial to generalizing over inputs, as your program may need to
perform similar work multiple times for different pieces of the input—and the number of
repetitions will change with the characteristics of the inputs. There is another way to
express repetition, called recursion, which you will learn about in the third course of this
specialization.

While Loops
There are three kinds of loops in C. The first of these is the while loop. The syntax for a
while loop is shown in this figure:

The keyword while is followed by an expression in parenthesis. Much like an if

statement, this expression is evaluated to determine whether or not to enter the block of
code immediately following it, which is known as the body of the loop. If the conditional
expression evaluates to true, the execution arrow moves inside the body of the loop and
its statements are executed normally. The while loop differs from the if statement in
what happens when the execution arrow reaches the closing curly brace. In the case of
a while loop, it jumps up to the top of the loop, immediately before the while keyword.
The conditional expression is then re-evaluated, and if it is still true, execution re-enters
the loop body. If the conditional expression evaluates to false, then the execution arrow
skips to immediately after the closing curly brace of the loop body, and proceeds from
there.

The next video shows the execution of a while loop.

do/while Loops
Another type of loop in C is the do-while loop. Unlike a while loop, which checks its
conditional expression at the top of the loop, the do-while loop checks its conditional
expression at the bottom of the loop—after it has executed the body. While this
distinction may seem contrived—either way the condition is checked between iterations
—it is important at the start of the loop. A while loop may execute its body zero times,
skipping the entire loop, if the condition is false initially. By contrast, a do-while loop is
guaranteed to execute its body at least once because it executes the loop body before
ever checking the condition.

The figure above shows the syntax of a do-while loop. The keyword do is followed by
the loop body. After the loop body, the keyword while is followed by the conditional
expression and a semicolon.

Execution of a do-while loop proceeds by first entering the loop body and executing all
of the statements contained in it. When the execution arrow reaches the while at the
end of the loop body, its conditional expression is evaluated. If the expression evaluates
to true, then the execution arrow jumps back to the start of the loop body. If the
expression evaluates to false, then it moves past the end of the loop and execution
continues with the next statement after the loop.

For Loops
The third type of loop in C is a for loop. The for loop is syntactic sugar—it does not
introduce any new behavior, but instead provides a more convenient syntax for a
common programming idiom. In the case of for loops, the common idiom is counting
from one number to another. The following figure shows the syntax of a for loop, and
how it is de-sugared into a while loop—that is, how we could write the for loop in terms
of the already familiar while loop. Knowing how the for loop de-sugars to a while loop
tells us how to execute it. We can imagine the equivalent while loop, and follow the
execution rules we have already learned for it.
The for keyword is followed by three pieces, separated by semicolons, inside of
parenthesis. The first of these is the “initialization statement”. It happens once before
the first time the loop’s condition is checked. In the de-sugaring, this statement appears
right before the while loop. The second piece is not a statement (even though it is
followed by a semicolon), but rather the conditional expression for the loop. In the de-
sugaring, this expression is the conditional expression of the while loop. The third
statement is the “increment statement”. In the de-sugaring, it appears immediately
before the close curly brace of the loop body. After all of these is the loop body, which
(except for the addition of the “increment statement” at the end) is the loop body of the
while loop in the de-sugared version.

If you examine the figure carefully, you will notice that there is a set of curly braces
around the entire piece of while-based code. These curly braces are there for a subtle,
but important reason. The scope of any variables declared in the “initialization
statement” of the for loop have a scope which is limited to the for loop. Recall that a
variable typically has a scope which is limited to the curly braces which enclose its
declaration. For a variable declared in the start of the for loop, the scope appears to be
an exception to this rule, however, it is not if we think of it in terms of the de-sugaring
shown above with the curly braces surrounding the declaration.

Nesting
Just as if/else statements may be nested, loops may also be nested. Similarly, loops
follow exactly the same rules no matter how they are nested. In fact, if/else statements
and loops may be nested within each other in any combinations. The rules are always
the same regardless of any combinations or depths of nesting.

Sometimes a programmer wants to leave the loop body early, rather than finishing all of
the statements in side of it. There are two possible behaviors that a programmer might
want when leaving the loop body early.

Break
One behavior would be to exit the loop completely, making the execution arrow jump to
immediately after the close curly brace which ends the loop (the same place that it goes
when the loop’s condition evaluates to false). This behavior is obtained by using the
break; statement—which we have already seen in the context of switch/case. Whenever
the execution arrow encounters a break statement, it executes the statement by
jumping out of the innermost enclosing loop (whether it is a while, do-while, or for loop),
or switch statement. If the break statement is inside multiple of these which are nested
together (e.g. a loop inside a case of a switch statement), then it exits only the most
immediately enclosing one. If a break statement occurs and is not inside one of these
loops or a switch statement, it is an error in the program.
Continue
The other possible behavior that the programmer might want to have is for the
execution arrow to jump back to the top of the loop. This behavior is accomplished with
the continue; statement. Executing the continue statement jumps to the top of the
innermost enclosing loop (if it is not in a loop, it is an error). In the case of a for loop, the
“increment statement” in the for loop is executed immediately before the jump. This fact
complicates the de-sugaring of a for loop into a while loop slightly relative to the
explanation given above. If the for loop contains any continue statements, then the
“increment statement” is written not only before the close curly brace of the loop, but
also before any continue statements.

The Execution of Continue lecture shows how to transform a for loop with a continue
statement inside of it into an equivalent while loop, then execute the resulting code. We
note that in this example, simply using an if/else statement would be better—however, a
good example of the use of continue is not easy to come by until we learn some more
advanced concepts.