This lesson focuses on one critical goal: staying sane in CS. Programming and computer science can be incredibly frustrating! Machines are highly-responsive but also highly-inhuman, and too much influence from them can be harmful.
We’ll address both left and right brain sanity. To satisfy your logical and critical left hemisphere, we’ll look into several of the common error messages that you’ll experience in CS 124 and discuss how to fix them. And to nuture your creative and intuitive right hemisphere, we’ll talk about how you stay human while learning to communicate with machines.
But let’s start with some debugging practice!
All programmers make mistakes. All of the time. But you learn two things with time. First, how to fix your mistakes quickly. And second, that you are never going to stop making mistakes, so you might as well get used to it!
Below we’ll walk through the three common kinds of error messages you’ll need to handle in CS 124:
checkstyleerror messages, caused by incorrect code formatting
Based on our prior experience, you should expect to make a lot of these mistakes. In Spring 2020, around 500 CS 124 students together made:
So get ready to make your own contribution to that total this semester. But there are some stategies that you can use to handle errors. Let’s go through each category one by one.
Some of you may not like these rules. That’s OK. You just have to follow them. Coding conventions like the ones that we enforce are ubiquitous in industry and in open-source communities. When everyone agrees on basic aspects of how code is formatted, everyones code becomes easier for everyone to understand.
That also holds true for CS 124. Our coding conventions are at least in part to help our course staff help you. Because your code is formatted how we expect, we can understand it more quickly and help you more easily.
checkstyle errors are frequently caused by whitespace.
Let’s look at some common errors and how to fix and avoid them.
Before Java executes your program it transforms it through a step called compilation. We’ll discuss this in more detail in a later lesson. But certain types of errors can occur during this step.
You can divide them broadly into two categories:
Let’s look at both of these scenarios and how to address the errors that result.
Just because the compiler doesn’t find any problems doesn’t mean that your code is correct! It can still cause an error when it is executed. Below we examine runtime errors and how to fix them:
A lot of the code that you write in this class will be tested to determine if it is correct. This is done by running your code—like a function, for example—with lots of different inputs. If we find a case where your code doesn’t match up with the solution, we’ll show you that failing input.
In the walkthrough that follows we’ll try and explain a bit about how the testing process works and how to evaluate the output.
Declare and implement a function called
You should accept a single array of
char values as your only argument, and print that array backwards,
one character on each line.
Your function should return the length of the array as an
Hopefully by now you’ll have noticed that writing correct code is hard. There are a lot of ways to make mistakes. So programmers are always on the lookout for ways to make their lives easier and attempt to avoid bugs before they happen.
One way to do this is to use another feature of Java known as
Let’s look at how they work:
One important caveat:
assert statements are not always turned on when you code is run.
Typically they are enabled during development (when the programmers are running the code) and disabled in production (when actual users are running the code).
But don’t worry:
assert is enabled on all of our playgrounds and for all of our homework problems.
We’ll ask you to start using it on homework problems soon!
Now let’s look at a simple example where we might want to use
Declare and implement a function called
arrayCount takes two arguments: an array of
ints, and a single
It returns a count (as an
int) of the number of times that the passed
int argument appears in the array.
Hopefully the walkthroughs and the statistics we presented above help convince you of one thing: you’re going to make mistakes. We have both good news and bad news about that:
All day we’ll be discussing frustration, failure, and sanity. Below we talk a bit about how we work through those feelings in our own lives, and how we try and maintain a positive relationship with technology.
The Accounting firm LambdaCalculator is running out of money. In the past few months, they've struggled to find new clients, and as a result they are looking at laying off staff. They've hired you to build some software that fulfills the role of their accountants. As the first step, you will write some code that calculates the gross profit (total revenue minus total expenses) for monthly financial reports.
Write a function called
calculateGrossProfit that takes in two
int parameters, the revenue for each day of a
month then the expenses for each day of a month, and returns the gross profit (revenues minus expenses) as an
You may assume that both passed arrays will not be
null and the same length.
Here's an example of how your class should behave:
Overall, women remain underrepresented in corporate tech leadership, occupying less than 25% of so-called C-suite positions: CEO, CTO, CFO, and so on. But that number is on the rise, thanks in no small part to groundbreaking leadership provided by the small number of women who have occupied highly-visible roles in the business of technology.
One of those women is Sheryl Sandberg, former COO of Facebook (and then Meta), and founder of
leanin.org, an organization created to empower women and help them achieve their ambitions.
Here’s a short clip from a TED talk that she gave including one of the many important observations she highlights about how women and men are perceived differently in the workforce:
Need more practice? Head over to the practice page.