Testing is great.

You're going to test your code like crazy,

and write lots of hard test cases so you can identify problems with your code.

But testing has its limitations.

For one thing, you can never write

enough test cases to guarantee that your code is correct.

Even if you write a million test cases which are all really clever and difficult,

there might be that million and first test case that your code would fail.

Also, testing will only tell you if your code has the right functional behavior,

if it produces the right output.

It won't tell you if you wrote readable code,

used good variable names,

wrote appropriate documentation, or a variety of other stylistic concerns.

These may not sound so important now as you focus on trying to get your code to work.

But when you are working on large projects with

many team members that last for months or years,

these concerns become very important.

So another way that you can help ensure high code quality is a code review.

Sit down with a colleague.

In a work environment, this be someone on your team.

Go through your code with them line by line.

Explain what each line does,

and why it does that.

You might even draw a diagram of the execution of your code as you go,

to make sure both on exactly the same page about what is happening in your code.

As you do this,

your colleague asks you questions and identifies potential problems.

They might point out cases that they think you didn't consider.

If you think you did consider them,

you can have a discussion about how your code handles that case,

and how you can make that clearer to future readers of the code.

They might also point out areas where your code could use

better documentation or any of the other readability concerns they see.

And of course, they might see other potential problems ranging from

security vulnerabilities to poorly phrased messages printed to the user.

The code review can take a variety of forms,

not just the one we talked about.

It may be that the case that

your colleague reviews your code without you there to explain it.

In fact in many companies,

someone must peer- review your code before it gets pushed

to certain branches like master of the git repository.

This ensures that certain quality guidelines are met with

all code that is integrated into the main branch of development.

The review could even happen while the code is being written,

as it happens in pair programming.

In pair programming, one partner drives,

meaning they write the code,

while the other partner navigates,

meaning they watch what the driver is doing,

look for problems and think about the bigger picture of where the code is going.

We aren't going to go deeply into these topics,

but we did want to mention them to you.

If you go on to take more classes on software engineering,

you will almost certainly learn much more about code reviews.

Code Review

Writing, Running, and Fixing Code in C

Meet the Instructors