Programming methodology lecture18

Programming Methodology-Lecture18
Instructor (Mehran Sahami): So welcome back to yet another fun filled exciting day of
CS106A. I'm feeling a little bit more relaxed. Are you feeling a little bit more relaxed? A
few people are nodding. A few people are like, "Yeah, Ron, we took the midterm in your
class, but we have like six other classes to deal with. You can feel relaxed, but we don't."
But don't worry, things in this class are just – it's all downhill after this. It's just a good
time.
So a few quick announcements before we jump into things. One of which is that there's
four handouts, and if you didn't get the handouts – if they weren't there when you came
in, they're all in the back now. You can pick them up after class. So you don't need to
pick them up right now. You can pick them up after class.
The midterms will also be back after class. I'll show the performance of the whole class. I
was very pleased. It was just – it was a heartwarming kind of thing to just see so many
people doing so well. But you'll get them back after class. So you'll get them today.
You – one of the handouts also solutions for the midterm, and so you can – if you got
anything wrong you can compare your answers with the solutions. One thing to also keep
in mind is that the actual solutions we were looking for are shorter than the solutions that
I give you. The solutions that I give you have comments. For one of the problems I
actually gave you two different ways of doing it just so you see different approaches. But
you weren't expected to actually write that much code. All we wanted was sort of the
code without the comments, which is actually pretty slim if you consider how much code
there is there without comments. But you'll get those back after class.
And then as you hopefully know, assignment number four is due today, and assignment
number five, you're next handout – one of your handouts is going out. For assignment
number five you will do yet another game because it's just so much fun to do games. And
this time we're gonna be testing your abilities with – we're not testing your abilities.
That's an awful way of saying it. We're going to be watching your abilities in the use of
arrays flower in terms of designing another game. Okay.
So with that said, it's time to see how much pain we actually caused on you assignment
number four. Hopefully not too much pain, although, I did hear there was quite a few
people on [inaudible] on the wee hours of the night last night.
So anyone in the zero to two hour category? Was that actually someone back there? No.
Just joking – yeah, kind of funny. Two to four hours? All right. A few folks. Good to see.
Four to six hours? Oh, nice. Six to eight? Pretty large contingent there in the old six to
eight category. Eight to ten? Wow, also pretty large contingent in the eight to ten
category. Ten to 12? All right. We begin to see the drop off at ten to 12. Twelve to 14?
Few folks at 12 to 14. Fourteen to 16? Sixteen to 18? Eighteen plus? Taking a late day?
That's – yeah. Alrighty.

Once again – it happens every time. I don't make this up, right? You saw people raising
their hand. The world is just – it's amazingly normal. It really is. There are two things the
world is – it's linear, and it's normal, not necessarily at the same time. So again, ten hours,
and less life is good. Even if you're in the ten to 12, you're still in pretty good shape. I
didn't see actually too many people up in this range, which is good to see.
If you're in the 12 to 14, it's still not very bad, right? It's just some – there might have a
bug or some particular thing that happened that caused a little extra time. If there was
some conceptual thing that did not get cleared up as a result of actually doing the
assignment, that's the whole point, right? Some times you might run into a roadblock, but
the point is once you get through that roadblock, that concept is cleared up for you. That's
the real point of doing assignments as opposed to just reading the book.
Reading the book's easy, and a matter of fact, it's surprisingly easy to read code, and think
that you could write it, right? That's what most people do. They look at code, and they're
like, "Oh, I could've written that." Right? It's like Jackson Pollock painting. You look at
that, and you're like, "I could've painted that." Right? But there's a difference, right? One,
he painted it first, and that's why it's worth like $20 million, and two, trying to actually do
the same thing later on requires a different creativity on your part than just looking at
what someone else did. So it's important to not just read code, and understand it, but to be
able to write code, and understand it, which is the whole point of the assignments.
Alrighty.
So with that said, time for some midterms statistics. So here is the stats on the midterm,
and that's just a beautiful thing to see. Right? This little hump over here – I should've just
tacked on to this, right? Then we would've actually had like a little inverse Poisson
distribution that you would've said, "But, Marron, it's not normal." And in fact, you can
approximate a Poisson to the normal, so it is.
But the important thing is that in fact the class did very well. There were six perfect
scores on the exam, which is why I broke out the 90's as a separate category, which it just
warms the cockles of my heart. What the cockles are, I'm not sure, but it warms them.
And a lot of people who did very well, right? A lot of people in the 70 or higher category.
Nice to see a very large contingent in the class in the 80 plus category.
And so the stats – this is out of 90, right. So this in not percentages, but this is out of 90
points. The mean was a 73.2. Median was a 77, which percentage wise translates into
almost 85 percent. And then the standard deviation was 13.6 points. So if you're kind of
over in this range over here, good times, happy days, life is good.
If you're kind of in this range over here, you want to make sure conceptually things get
clarified. You want to look at your exam, and figure out whatever problems there were,
look at the solutions, get them clarified, get the issues clarified in your mind. If they're
not clear, talk to your section leader this week, talk to me, talk to the TA to get any
concepts cleared up.

If you're kind of in this range or lower, it's – to be honest, it's time to worry a little bit,
and you need to really –think of the midterm not as just, "Oh, my God, my grade is
ruined," because the point of having midterms, at least as far as I'm concerned, is not just
grades. It's great if everyone does well, and we just give more A's, and life is good. But
really it's a diagnostic for you. It's a chance for you to get a realistic calibration of how
you're doing relative to the rest of the class, relative to what we expect you to know.
And so if you find yourself from that calibration falling into a range that worries you a
little bit, that you shouldn't think of as, "Oh, it's just time to pull your hair out, and panic."
All that really is is an indication that you need to come clarify some concepts. And
maybe they're clear for you, and something bad just happened during the exam, like an
earthquake. Or maybe it's some conceptual issue that needs to be cleared up, and this is a
chance while we're still well before the final exam, and well before several other
assignments in the class to get that clarified for you. So think of it as a diagnostic. Okay.
So any questions about anything related to the midterm before we sort of push off into
our next great topic in computer science? But I was just very pleased. It just made me
happy. It made me think like you had the easy button with you, and you just saw the
exam, and you were like, [Easy Button] That was easy. Yeah.
It's just like – I got this thing – well, I got – I'll tell you the story. I bought this thing like a
year ago, and I was like, "Oh, this will be great for class." And then it sat on a counter for
a year. So now I'm happy that I can actually use it. And it is not particularly branded
because I cut that off just in case someone wants to sue. All right.
So with that said it's time to actually get into our next great topic in computer science. So
I'll just leave this up here if you want to write down these numbers for whatever reason.
But to wrap up a little bit about one of our last great topics, which was arrays, and
specifically multi-dimensional arrays. And I'll just call them multi-dim arrays. And
you've seen a couple examples of these right now, but I want to – already, right, in the
last couple classes you saw some examples of multidimensional arrays. But I want to
show you yet another example to show in a very nuts, and bolts kind of way how funky
things get when you have arrays of arrays, and you pass them around as parameters in a
program – just so you see yet another example to drive the point home.
So let's say I was gonna write a program to, oh, keep track of midterm, and final scores,
for example. And let's say the class was smaller than this. So I had at most 100 students
because I was teaching some class like basket weaving or something, and it's just small.
It's cuddly. We all hold hands. So I have some two-dimensional array that I want to have
because I want to have midterm scores, and final scores, but I want to keep them
separate. So I'm gonna have one array of midterm scores, and another array of final exam
scores.
But in some sense what I really have is a two-dimensional array that's two by the number
of scores that I have as a maximum. So let's say 100 is the maximum number of scores
I'm gonna have. So I'm gonna a two by 100 array, and I'll call this scores, and I'm just

gonna create this by basically saying new int. And you've seen the syntax before. Two –
and this is 100. And these would probably be constants that I would have in a program,
but just to save space, and save time, I'm not – you actually declare public static final int.,
and saw max size 100. So I'm just gonna put 100 in there.
And as we talked about a little bit before, some particular entry of this grid, right –
because this is just a two-dimensional grid – like score zero comma zero is just – this is
just a single int. basically. But then we talked about this funky thing where we said,
"Hey, you know what? A multi-dimensional array is actually an array of arrays." So a
two-dimensional array's an array of arrays. A three-dimensional array is an array of
arrays of arrays, right?
So we could actually think about, "Well, what happens if I only specify one of the
dimensions of the array?" So what do I get if I say, for example, scores sub zero, right?
That's not one entry, so it's not an integer. That's in fact a whole array, right? The way to
thing about this is I have two arrays that have size 100. All right. So we have a little
break in there. And so score sub zero is this array, and score sub one is this array, and
scores is kind of this array of arrays, right? It's really an array that has two elements. So
this is element No. 1 over here in the heavy chalk line of the array or element No. 0 – it's
the first element in here is element number one. Okay.
So this thing – the type of this thing is really an integer array. And that's the funky thing
to kind of think about. Okay. So score sub zero behaves in your program just like if you
had declared a one-dimensional array, which means you can pass score sub zero to a
function that expects a one-dimensional array, and that's perfectly fine. What it's doing is
passing this element of the scores array of arrays, which happens to be a whole array of
integers in its self. Okay. So any questions conceptually about that? All right.
So why don't we look at a little code that actually drives that point home. All right. So
we'll put this away. Bye-bye midterm scores. Don't save. And we'll come to our friend the
Eclipse, and we'll say, "Hey, Eclipse –" oh, we'll get to Roulette in just a moment. Don't
worry. It's all about gambling in this class. All right. So it's not really gambling. All right.
So I'll tell you we have a program that wants to keep track of test scores. So here what
I'm gonna do is I'm gonna have a program test scores, again, we're just gonna set the font
to be large. It's not a big deal. And I'm gonna ask the user for the number of scores. So
I'm gonna ask the user for number of scores, and whatever the user gives me is num.
scores. I'm going to create my scores array to be a new array of integers that's two by
however many scores you have.
And you should see this right now, and you should go, "But, Marron, you're missing the
declaration of scores, right? This creates a new array of arrays, but where's the
declaration of scores?" Ah, instance variable. So I want to show you an example of where
we have an instance variable that's an array of arrays. So here I declare the instance
variable. This just tells me that score's is going to be a two-dimensional array.

It is not yet created the two-dimensional array. It is just set – I'm gonna have this thing
called scores that gonna be a two-dimensional array, I still need to create it. So when my
program runs up here, I ask the user for the number of scores, and I actually create the
two-dimensional array. I don't need to declare scores because scores was declared as an
instance variable or an ivar, so it's already declared. I need to create all the space for the
all the elements of that array. Any questions about that? Hopefully that's clear. All right.
So first thing I'm gonna do is I'm gonna initialize my scores, and here – and its scores. All
this is gonna do is have two for loops that are gonna go through, and set all the scores in
the grid to be zero to begin with. Now, I told you before, when you declare an array –
when you create an array, the values of the array get initialized to be the default value for
that type. And the default value for integers is zero. So you might say, "But, Marron,
they're already zeros anyway, so why are you doing this?" I'm just doing this to kind of
exemplify the point. I could put in a one here, and just say, "Hey, everyone starts with a
one on the exam." Right? But we'll just say it's zero.
How do I actually think about this two-dimensional array? Well, first of all, I want to
think about the rows of the array, and then for every row it's got a certain number of
entries or essentially the number of columns in the grid. So how many rows are there in
the array? If I look at the two-dimensional grid scores, and I say scores dot length, and
scores is an array of arrays, it tells me what is the size of the first dimension, right? So if
scores is a two by 100 array, what's the size of the first dimension? It's two.
So scores dot length – the way you want to think about it is this is scores. How big is
scores? Scores actually is of size two. Each of the elements of scores of size 100, but if
each of the individual entries of scores – score sub zero, and score sub one – is an array.
So there's only two arrays inside scores. So scores dot length, back over here in my
program, will in this case have the value too. Okay. So that's gonna be my outer loop. My
outer loop's gonna say, "I want you to loop over however many rows you have in your
grid, " is the way to think about it.
For every row, how many entries do you have in that row? What I'm gonna do is I'm
gonna say, "Hey, all the rows have the same size, so I'm just gonna arbitrarily pick the
first row because I know there's always gonna be one row. If I knew there was always
going to be ten rows, I could say, "Score sub nine." But for programmer, they're just like,
"Why are you doing score sub nine?" So the general idiom – the way we using do it, is
just score sub zero because you always know that there is a first – always a first entry in
an array – or in an array of arrays.
So score sub zero, what is that? Score sub zero I just told you is a whole array of integers,
right? It's this thing right here. So its length is 100 because there's 100 integers in it. So in
this for loop we loop through 100 elements, and so all we're gonna do inside here is we're
gonna set scores I sub J. I's gonna very from zero to one because it's actually gonna count
from one to two, but not include two. And J's gonna vary from zero to 99. And so it's –
we're gonna set all the elements of the grid to be zero. Any questions about that?

The syntax just kind of looks funky because here we have scores without a sub script on
it. Here we have scores with a subscript on it. In both cases we're taking the length. And
the important thing to think of conceptually is it's an array of arrays. So when we just
take the first length, we're saying, "Hey, how many sub arrays do you contain?" It says,
"Hey, I contain two arrays. I'm an array of arrays." And when we take the length of the
first sub array, we get the actual number of columns for a grid. Okay. And you can
generalize this to three, and four dimensional arrays, but for this class really all you're
gonna need to worry about is two-dimensional arrays at most. Okay.
So that's gonna initialize all the grid to be zero. So that's what an int. scores is gonna do.
And then we're gonna write out score sub zero before we do any incrementing – action
increment all the scores inside because it's just good to give everyone points.
But before the increment, we're gonna print out the scores array at score sub zero. So if
we look at print list – right – all print list does is – this is a really simple thing. It just gets
passed an array of integers. It goes through all the elements of that array, right? So we
just are calling the array list in this case, so it's just counting up from zero up to the length
of the list, and just writing out all the individual elements, one on each line. So it's a
trivial thing to write. You've seen this a whole bunch of times with arrays so far.
But what are we passing to this guy, right? This guy's expecting a one-dimensional array.
What we're passing is score sub zero here, which means what we're passing to it is just
this single entry from the scores grid. We're passing a sub array of the scores grid. We're
passing the very first array that's at score sub zero, which means score sub zero here is a
whole array of integers, and that's the type this thing's expecting, so everything's perfectly
fine. It may seem weird that we're sort of taking this grid, and dissecting it into its
individual rows, but the important concept – and I'll say it once again – each one of those
individual rows is just an array in itself. Okay.
So last thing I want to do besides just printing out the scores, I want to go through, and
increment the score list. Now, here's something that's funky. An increment score list – I'm
gonna pass in one of the sub arrays. I'm gonna pass in score sub zero.
What is increment, and score list do? It's expecting an array of integers. It just has a loop
through that list, and it's gonna go through, and just add one to every entry in that list,
right? Very standard thing you would think of doing maybe with some array of numbers.
You just want to go, and add one to it. And that's all this method is doing. The only thing
that's funky about it is when we call that method, we're passing it a portion of the scores
grid, which is just the first array in that scores grid. Okay.
So any questions about any of this? If this is all making sense nod your head. Excellent.
If it's not making sense shake your head. Feel no qualms to shake your head. Good, good
times.
So let's run this. We'll be happy. We'll just make sure it's working. I'll give it a small
number of scores because it'll be like a tiny wee class. How many – I should just ask.

How many people are in the smallest class that you happen to be in not counting the
instructor? Anyone lower than five? One. How many people are in that class?
Student: Four.
Instructor (Mehran Sahami): Four. That's less than five. And as a matter of fact, that's
all you need for candy because one is – one here – and that's amazing, right? It's just a
class of four people. That's a good time. Sometimes – all right.
So we'll say the number of scores is four just to emulate your class, and everyone started
with a zero, and then they all got a one, which in a class of four people probably means
100 percent. All right. So that's all it's doing, right? And all of this is in terms of score sub
zero. Score sub one has the value zero. It still maintains the value zero. We never touched
it when we were doing the incrementing. So any questions about that? No. No. No. All
right.
So besides just doing life in this array way, you can also do things in the array list way.
Okay. So we talked about arrays, and array lists. So here I'm just gonna have a single
array of – array list of scores. And what I'm gonna do here, just so you can see the syntax,
is again, I'm gonna have a private instance variable that's my array list scores that's an
array list of integers. I only have one, and I'm not asking the user how big it needs to be,
right, because array lists are dynamically sized. It doesn't matter. As the user keeps giving
me scores, it's just gonna get bigger, and bigger. So I don't need to have the size a priori.
So in my instance variable, I actually not only declare scores, but I actually create the
array list. So I create a new array list. It's empty to begin with. I can just add stuff to it.
Not a whole lot of excitement going on there.
What do I do? I'm still gonna ask the user for the number of scores, but here when I'm
initializing my scores, I don't need to worry about creating an array of a particular size.
Here I just say, "Hey, you gave me some number of scores. You want me to initialize this
array with how ever many scores you gave me." So I'm just gonna go, and do a for loop,
and add that many elements to the array list because every time I add, the array list just
automatically grows in size to be able to store all the scores. And I'm gonna store zeros.
Well, as you know a priori, right, zero is just an int. It is not an integer. So in Java 5.0,
and later because life is happy for us now, we get this automatic boxing, which means the
computer sees the zero, and goes, "Oh, that zero's an int." Your array list stores integers,
right? That's the parameterized type of your array list. So I'm automatically gonna box up
your little zero like you're at the integer restaurant, right, and it's like, "Oh, I got this O."
And it's like, "Yeah. Yeah. I can't eat the O, let me box it up for you as this thing called
an integer, and then you can have it." And then it says, "Oh, I can add an integer to
scores." And it just takes care of that for you. Okay.
So when it scores it just goes through, and adds that many zeros to the list, and then we
can write out the scores before we increment, and we'll print list our scores. And all print

list does is – you've actually saw this exact same code last time. It has an array list. We
don't need to specify the parameterized type here. This will just work on any kind of
array list. It goes through up to the size of the array, and it gets each of the individual
elements, and prints them out. Okay.
So all we're gonna do now – the interesting part is to increment the score list. Here again,
we're gonna go through scores up to the size of scores, but the syntax looks different. The
syntax is actually a little bulkier than our array syntax, so we could just say, "Scores sub,
you know, I plus/equals one." Right? To add one or plus plus if we just wanted to add
one.
Here the funky thing if we want to set a score is inside the scores list we have to use the
set method. There's two parameters we sent to the set method. The first is the index. So
we're gonna say, "Set at location I." So whatever the old value was, we don't care. We're
just gonna slam something new over it, but set something at val – in place I.
What are we gonna place at location I? We're going to get whatever was previously at
location I, which is an integer, and we're gonna add one to it, which means if I have this
thing that's an integer, and I want to add one to it, I take that integer, I un-box it to
become an int. This happens for you automatically. So I get the int., which is zero, which
is what I put in there before. I add one to it. So now I have the int. one, and now I want to
store it back into something that's stores integers, so it automatically gets boxed up for
you as this integer, and gets stored back.
So the syntax looks a little bulky, and that's really the point of showing this to you. It –
sometimes using array lists can actually be a bulky thing to do. But if we go ahead, and
run this – do te do te do – we're running. We're running. Life is good. It chugs along. I
got to get a faster Mac. Alrighty.
Test scores with array lists – and it's gonna ask me for the number of scores. We'll say
three this time because someone in your class dropped. And we had three zeros that got
entered to begin with, and then we went through, and for each one of those zeros we sort
of took the zero, added one to it, and stuffed it back in. So we got three ones. Not a whole
lot of excitement going on there, but you see the difference.
So when you see these two things one natural question that kind of comes up in your
head is, "Okay, Marron, I sort of see two ways to do this. Which one should I use?
Should I use an array list or should I use an array? And as a matter of fact you just told
me on this next assignment I'm gonna be working my array muscles. So what's a good
idea to think about?" Okay.
And here are the pros, and cons. So if we think of array lists – and I'll just give you the
pros, and cons relative to array lists versus arrays. The pros of an array list, right, are that
at – the biggest pro is that it has this dynamic resizing. So if I need to add more elements
– if I don't know the size a priori, this is a great way to go because it automatically
resizes. Okay. And the other pro that it has is there is a bunch of high-level operations

that automatically supports things like contains, right? So you can just see if an array list
contains a particular element or not. So it has other operations – I'll just say ops. that are
provided for you. Right? Which is a nice thing to have – so you don't need to worry about
going, and finding some element in array.
It does have some cons though, and the cons are that it's less efficient in terms of how the
computer actually deals with an array list versus an array than an array. So it's less
efficient than an array. The other con that it has is its syntax can get kind of bulky. Syntax
is bulky because if a lot – one thing that I really want to do often is if I want to have some
array, I want to make some modifications to values in that array. Well, in an array I just
say, "Hey, you know, I have score sub three, and I stick in some value, and life is good."
Or I say, "Score sub three plus/equals five, and I add five to it, and life is good."
Here the syntax is bulky because I need to say, "Get the old value, do the modification to
it, and then set it as the new value." And so I'm really doing two method calls every time
I want to get, and set a meth – a value, and that's just bulky. And bulk means it becomes
more error prone.
The other thing is in the pre-Java 5.0 world. So we'll just say pre-5.0, which would you
sad, and weep, and any time any – or if you run into any friends that are using a version
of Java earlier than 5.0, you should just pat them on the shoulder, and take a moment of
silence with them, and then like – I wouldn't say slap them around, but I would say,
"Encourage them strongly to get a newer version of Java." Pre-5.0 – this was
horrendously bulky to use because all of that boxing/un-boxing stuff didn't happen
automatically, and you had to worry about, "Oh, I need to box, and I need to un-box." It
was a bad time.
The main difference – and you might say, "Yeah, well, you know, I don't care about
efficiency, right, Marron? I got a whole bunch of memory, and my computer's fast. And
yeah, bulky syntax, I can deal with that because I cut, and paste anyway. And I'm using
Java 5.0 or later, so I don't really care about any of this, man. I'm just – I'm going the easy
route."
And the real big difference – the thing to keep in mind for one versus the other is if you
know the size of your array beforehand – if you have a fixed size, almost always go with
a regular array, not an array list. Keep that in your mind when you're thinking about the
program that you're going to be writing. Fixed size – there's a lot of things for which you
know they will have a fixed size or some maximum size. Hum. Let's take a moment to
think about that. Fixed size – your next program – array. Good? All right. So just in case
it wasn't clear. All right.
So now, with that said, it's time to actually move onto the main topic for today. So any
questions about array versus array list? Hopefully that should be clarified. All right. And
you should just be thinking right now, "Oh, Marron, [Easy Button] That was easy." Can
you even hear that? [Easy Button] "That was easy." Yeah. That's what I'm talking about.

That was easy broadcast in stereo. All right – which means it's easy from two different
sides.
So now, the thing to think about is our friend debugging. All right. Which is something
you've done this whole time, and you're like, "But, Marron, I've been doing debugging
this whole time. How can we have a whole lecture on debugging?" Well, because it's time
to think a little bit about that zen, and the art of debugging, and actually a bunch of
practical tools I'm gonna show you to do debugging. Okay.
The first thing to think about debugging is when you are a computer programmer or
software engineer or in the larger sense computer scientist, there are different roles you
play when you're building software. There's a portion of your time which is spent on
designing software, and here you're really like an architect. You're kind of looking at big
pieces, and how they fit together, and drawing schematics, and figuring out what your
sub pieces are, and doing decomposition, and the whole deal.
Then you go into coding. And when you're a coding – when you're coding, you're an
engineer. Woo-woo. You got you're little hat on. You're in your train. No. You're writing
code, and you're thinking about good software engineering, but you're building
something, and you're driving a process forward.
Then there's this thing called testing, which you do to your code. And a lot of times that
means it's 4:00 a.m., you think your code works, the project is due tomorrow, and you
decide, "Hey, I'm gonna do some testing." And this is the role that does not get taken
seriously because it's 4:00 a.m., and your project is due. Often times testing means, "Hey,
I ran it once – maybe twice, and I felt good, and I stopped. And I tried the simplest
possible case I could try."
That's not the role you want to play when you're testing. When you're testing, you're the
vandal. And that – like you got the spray can in your hand, and you're like, "Yeah, we're
going out." You are thinking about, "What do I need to do to break this program?" You're
not thinking about, "What's the least I can do to please make the program run once, and
get through, and hopefully there's no bugs, and if it makes it through once, I'll just believe
it's correct, and that's a good time, and I'll turn it in?"
You're just banging on the thing until you break it. As a matter of fact, a lot of software
companies – most good software companies have people who this is their whole job,
right? They don't do this. They get code from other people, and just try to break it. And
this is a skill. You actually – you see some amazing things that people do to break code,
but they do it, right? And you got to appreciate that because when you're writing your
paper on your word processor at 4:00 in the morning, and it crashes, this person wasn't
doing their job because you found the crash, and they didn't. Okay. So that's what you
want to think about. You really want these people to be vandalizing the software. Okay.
And then after the vandal comes along, and smashes everything up, then you have this
job that's left to you, which is debugging. And when you're debugging, you could think,

"Well, I'm the police officer, and I go, and track down the vandal, and make them stop."
In fact, no, you want the vandal to keep vandalizing. You're the vandal. You got to keep
trying to break your software, but at the same time you're a detective to try to find out
where the breaks are happening, and how to fix them. Okay.
Now, here's something that people find a little odd, and I like to call them the four – well,
some people don't find them odd. The people who do software engineering don't find
them odd. I like to call them the four D's of software. Okay. And the first D is design.
You've already seen that. And then there's development, which is actually writing your
code. And then there's debugging. And then – anyone know what comes after debugging?
You're like, "D party." No. Deployment. Okay.
And in this class so far we've focused on design, and development. And now, we're
gonna spend some time thinking about debugging. And deployment is kind of like when
you give it to your section leader. We don't want to worry about like you released
software version 1.0 of your hangman program, and then we're like, "Oh, so when is 2.0
coming out?" And you're like, "Hum? Let me get back to you on that." And then you
issue a press release, and the dates slip, and shareholders get angry. All right.
Yeah, like – see we should have CS106a shareholders for like, "When is hangman
coming out? Oh, my God, you slipped the deadline." All right. Then you'll know how
serious those late days are.
Then there's deployment. Okay. And the one thing that I would pause at, and actually a
lot of people agree with, is that any problem that cascades from one step to another
causes a factor of ten times in the cost to fix it. Okay. Which means you come up with a
bad design for something, you're gonna spend ten times as much time writing the code
for that bad design. And the bugs that come up as a result of bad design are gonna be a
100 times as costly to fix. And once that software gets shipped out into the field, and the
only way to fix it is to issue a new version, that's a 1,000 times more expensive.
And people look at this, and they're like, "But, Marron, you can't be serious, right? How
could it be a 1,000 times more expensive?" Well, let me give you a little example. How
about our friend the space shuttle? All right. We have a space shuttle mission going on.
Space shuttle had an initial set of software that was written for it. Okay. Right.
And we're thinking like, "Oh, you know, like in tex." How much do you think one line of
code costs when they were all said, and done? If you think of the total amount of money
spent on the software development effort for the space shuttle versus the number of lines
of code that were written, how much did it cost per line of code? Anyone want to venture
a guess?
Student: [Inaudible].
Instructor (Mehran Sahami): Like dollars. $10.00. That's kind of fun. That's probably a
job I'd take. Anyone want to venture another guess?

Student: [Inaudible] thousand.
Student: $1.00.
Instructor (Mehran Sahami): $1.00. Higher – higher. Does that scare you?
Student: No.
Instructor (Mehran Sahami): Does that scare you? I'd take that job. I'd be like,
"$1,000.00 a line? Yeah, today in tex. Tomorrow, [inaudible]." Right? Like I'll take that
job. That's the right number. Okay.
There is about 500,000 lines of code – and now there is more – but in the initial version
of the space shuttle, and it took a total cost of $500 million to develop that software.
Okay.
So this is serious, right? This isn't something where we're like, "Yeah, it's fine, and we're
vandals, and we're debugging." Right? When you're on the space shuttle, you better hope
someone was doing their job doing this, right? Because if something's wrong, you can't
fix it up in space, right? In space no one can hear you scream – well, if you're in the
movie "Alien.” But if you're on the space shuttle, it's real difficult to actually fix
software. Okay.
Mars Rover was actually lost because of a software issue. Not actually – well, it was a
software design problem that came up. All right. Anyone know what the design problem
was?
Instructor (Mehran Sahami): Yeah, it was basically two different – it wasn't – it was all
basically the same difference as feet versus meters, right? One person was coding to a
spec that said, "Oh, the input you're gonna get is in feet." Another one thought it was in
meters. Right? Those are off by a factor of three. That's enough to kill the project. And
guess how much money was spent on that thing. A lot. All right. So it's important to think
of this – well, so how do you actually think about doing good debugging?
So the way we want to think about debugging is in some sense it's a river. And you're
like, "What? What is Marron talking about?" It's – this is a river. This is the river of your
program flowing. All right. And it's just nice. It's wonderful. And you're like sitting there,
and you're having a picnic down here, and the sun is shining, and the birds are chirping,
and you're like, "If my program gets here, and life is good, everything's just fine."
But what happens when the river is flowing? You run your program, and you get all this
sewage down here. And you're like, "Having a picnic next to sewage is no fun." Well,
what happened? So you go all the way upstream, and you look at the beginning of your
program. You say, "Well, at the beginning I knew I had no bugs because my program

didn't contain any lines of code." And somewhere along the way as my program's running
there was – oh, say this factory that was belching sewage into your water stream which
showed up at the end when you're running your program, and this thing is a bug.
And often times the problem is there is not just one. If there was one you'd be like, "Oh, I
can it. That's all good." Yeah, there's like factories all down, and up the river. There's
some on the other side of the river. There's some in the middle of the river. All right. It's a
bad time.
So how do you find those factories that are belching sewage? So here are some things to
think about. First of which is the mindset of what causes – what tends to cause bugs.
Okay. There's three things. I wouldn't say they cause all bugs, but they cause the vast
majority of bugs. One is bad variable values. Okay. Some where in your program you
have a value that is not what you expected, and as a result your program is doing
something that it shouldn't do. What that tells you if you think about this mind frame is
knowing the values of your variables at different points in your program is critical to
understanding when the bad values entered your water supply.
Second of which is faulty logic, right? You meant for the computer to do X. You
programmed the computer to do Y. Right? X, and Y were not the same. There's no such
thing as a computer glitch. The computer does what you tell it to do. And so you might
say, "Hey, the computer's not doing what I told it to do." Yeah, it's doing exactly what
you told it to do, you just didn't tell it to do the right thing.
And last, but not least, and this is probably the biggest one is unwarranted assumptions.
Right? "Hey, I thought the value were gonna be meters. You didn't tell me they were feet
until after the mission launched, and we lost the Rover." Think about what you're
assumptions are. And that's why when we talked a long time ago about pre and post
conditions – right – when we talked about it in the little world of Carol – "Oh, we just
didn't want them to walk into a wall." That was what assumptions were all about. What
can your method assume when it's called, and what can you assume after your method's
actually done, and do those match up?
So the things to keep in mind – and these are s – part of the zen of programming –
debugging. And then I'll show the actual doing of debugging. Okay. People have a
tendency to look for complex problems. Most of the problems are simple. So don't fool
yourself into thinking a problem always has to be complex to be a bug. Some times it's
just a very simple piece of faulty logic or some value that you mistakenly added one to or
added three to some where that you didn't mean to under some conditions. Okay.
Be systematic. There's a tendency, and this tendency tends to increase as the amount of
time left until the deadline for the assignment decreases, which is to just haphazardly
jump around code, and be like, "It's got to be here some where. Is it over here?" No, that's
the game I play with my one and a half year old son. "Is he over here? No. Is he over –"
and he's just standing there with his hands over his eyes because he has the simple idea in

mind, and I'm looking for something complex, but I'm not being systematic. I'm just like,
"Is it over here? Is it over here?"
And then finally at the end, right, had I just started at the beginning of my program, and
began to trace it through, I would've found my problem. But I have a tendency not to do
that. And part of the reason I have a tendency not to do that is that I make assumptions
about where the problem is.
Now, hunches are great. It's great to think about, "Oh, I think the problem should be
here," and have some intuition, and hunch about that. But when you have an intuition
versus a fact, and the two collide – this is in your eleven rules of debugging on your next
– on one of your handouts that you get. The fact always wins. Right? Your hunch never
beats out a fact. So if you make assumptions about the problem, and you don't see the
problem in the place of the code where you thought the problem should be, maybe the
problem's not there, and you need to reassess your assumptions about those pieces of
code that you thought were simple, and so they were error free, and in fact the error could
be there. Okay.
Other thing is be critical of your code. Right? People have a tendency to look at some
function or some method, and they think, "Oh, it's super simple. There can't be an error
there." Or they just glance over it. I've actually seen at major software development
companies, very large pieces of software written by brilliant, top of the line software
engineers who the problem in their code was this instead of this. Right. It was harder for
them to find that bug than to find issues with, like, memory, and garbage collection, and
leakage, and all this other stuff because they were just used to that. Right?
They weren't critical of things like this. And when they finally saw this error you could
just see like the eyes just nearly pop out of their head, and their head was gonna explode.
But that's all it was. It was something simple they just – the code – they glanced through
that code a thousand times and couldn't find it because they just didn't look at it critically.
Okay.
And last but not least – and this is the important thing at 5:00 in the morning where
you're programs not working. Remember this. Trust me. Don't panic. Panic is the worst
thing you can do with bugs. And why? Because people sit there, and they think, "Oh, my
God, there's this bug in my program, and it's over here. No, it's over here. No, it's over
there."
No. Your code's not changing unless you change it. If you have a bug in your code,
there's a bug. It's in one place. It remains in one place. Every time you run your program
it's in that same place just begging you. It's like, "Come on. Come find me. Did he find
now? No. Come on. Come find me." It's just there. It's that same little line of code, right?
How many total lines of code are there? Like a couple hundred at most, right? It's in
there. It's not moving. It's up to you to find.

Don't panic about it. Be systematic, question your assumptions, be critical of your code,
and eventually you'll get there. But if you panic you won't because you won't be seeing it.
Okay.
So what are some approaches we can take to debugging now that we have some of the
basic sort of philosophy down, and the fact that the real critical thing is don't panic? The
simplest approach to debugging is something that's called printf debugging, and printf is
actually something that comes from the language C.
The way you can think about it is println debugging. And the basic idea is right – if bad
values are the problem with your program, which in most cases they are, put some extra
printlns in your code that tell you what the value of your variables are at different places
in your code. Use printlns to let you know that you called a particular method. So at the
top of a method just have a println that says, "Hey, method X just got called." And right
before that method's supposed to be done, you add another println that says, "Hey,
method X is just about to finish." And if you notice some problem that happens between
those lines probably something's going on in method X.
Another thing you can do is just write out the values of your variables. And that's
probably the thing I would recommend the most. At different places in your program just
stick in printlns, and see is the values that you expect there matching what you thought
was gonna actually be. Right? And if they're not you can sort of see at what point did the
variables change the values that you didn't expect, and so something bad must have
happened between the last time you saw the values that were okay, and the time in which
they became bad. Okay.
The other thing – and this is a little bit more involved, but a not a big deal. It's something
called unit testing. Right? People have a tendency to test their entire program at once.
They write the program, and they run it, and something doesn't work. Well, why not
actually test out individual units or individual methods in your program, right? Write a
call to a particular method where you pass in the values for all the parameters with known
values, and see if the thing that it gives you back is what you expected it to do.
That's called unit testing because you're just testing one unit at a time. And when you're
done doing the testing you can take those calls out, and run your whole program. But
when you write some method, especially if it's a complicated method, just write a couple
lines at the top of run that the first thing they do is call that method to see if it's actually
doing something reasonable with some artificial values that you give it. Okay.
So, one way that you can combine a lot of this stuff is if you happen to be working in a
development environment that gives you facilities to do debugging more easily. And so
I'll show you, if we come to the computer, Eclipse actually has a very nice debugging
environment. Okay. And so rather these printlns, you can do sort of in any program, right,
because even if you're doing a program that you don't have a nice debugging
environment, you can still do println, and life will be good.

So let's actually debug a program using the debugger in Eclipse. So here's a little Roulette
program, and the way Roulette works is we're gonna have some constants to begin with,
how much money you start with, and how much you're basically wagering or betting on
every spin of the Roulette wheel. So the way Roulette works is we have a big wheel that
we spin. And here's all the rules of Roulette down here. I'll just show you the rules. Ah,
too much text to read.
The basic idea is the wheel has a bunch of different numbers on it from zero to 36 all sort
of consecutive numbers. And the way you can bet on numbers is you can either bet for an
odd number to come up, an even number to come up, a high number to come up, which
means a number in the top half from 17 to 36, or a low number to come up, which means
from one to 16. And you might – or if – one to 18.
You might say, "But, Marron, what about zero?" Zero is always a loser. So, zero doesn't
count as an even number. It doesn't count as a low. It's just always the losing value. And
the reason why that exists is because that's the house's advantage. It gives them a slight
advantage of about three percent over the player, and that's how in the long term they
make money because zero is always a winner for the casino, never a winner for the lo –
the player, other than that, everything's even money. If I bet $10.00 on low, and a five
comes up, which is in the low half of the range, then I win $5.00. Okay.
So that's what the instructions basically say. Just a bunch of printlns they write out in
instructions. Okay. We're gonna have a random number generator, rgen. That's an
instance variable that's just generates random numbers, and it gets an instance of the
random number generator. Hopefully after Breakout, and Hangman, this should be fairly
comfortable to you.
And now we kind of come to the rest of the code. Okay. First thing I'm gonna do is set
the font to be big. I'm gonna write out the instructions, and then I'm gonna play Roulette.
And so I say, "Hey, in playing Roulette I have some starting amount of money that the
user gets. As long as their money is greater zero, I tell the user you have some amount of
money. I ask them which betting category they want to bet." That means either even or
odd or high or low. So they type in a string. There's four betting categories.
I spin the Roulette wheel to get a value between zero and 36, and then if the winning – if
there's a winning category based on the outcome that they have, I give them – I basically
say, "You won this amount," and I increase their amount. If they didn't get a win in that
winning category, then I say, "The number is not –" basically, "That number is not
whatever you bet. So you're gonna lose." And I subtract the amount of wager from the
total money. And if they happen to get out of this loop then their money is down to zero,
and I say, "You ran out of money," and we stop. Okay.
So I might just run this program. Do te do te do – and see what's gonna happen. Notice I
didn't show you all the other code yet? Because I want to show you the facilities of the
debugger rather than just having you stare at code for a bunch of time, and try to debug it

because that's not the way you want to debug by just staring at code. You want to look at
what the symptoms are.
So here we're gonna run Roulette. And it writes out all the instructions, and it says, "Enter
betting category." And so we'll say, "Hey, I'm gonna bet even." "Ball lands on 33. That
number's not even so you lose." I'm like, "Okay. I'm gonna go for even again." Good old
even. Even always wins. "Number 35. You lose." "I'm going for even again." "27, you
lose." "Even come on." "Nine – 31 – 15 –" and then you're like, "I had so much faith. I
lost all this money, and then ball landed in two, and I still lost money."
And you just kind of sit there, and you're like, "Yeah, this casino's not really what I had
in mind." And you try to leave before the bouncers get involved. But you realize you
actually have a bug in your program, right? You bet on even. The ball landed in two. That
should be an even number. And you still lost money. So then you think, "Okay.
Something's wrong. What's wrong? Well, let me figure out right – this winning category
thing, I should've said, 'If the outcome moded by two or remaindered by two was equal to
one that should be odd. And if the remainder after I divided by two is zero that should be
even.' So I would've thought this would've been the case. What's going on here?"
And so what I can do in Eclipse is I can set up what's called a breakpoint. The way you
set a breakpoint is that a particular line over here on the gray bar you click twice. And if
you click twice, notice I got that little circle there. Can you see the circle on the very edge
of the screen? That's called a breakpoint. That means if I run the program now with the
debugger my program will stop at that point, and allow me to look at, like, values of
variables, and other kinds of things. Okay.
So I set that breakpoint by double clicking, and now I need to run again. So the way I run
again is see this little bug up here. That means run with the debugger. See up here? It
looks like a little tiny bug. So I click that to run with the debugger, and now it starts
rerunning my program again. And it says, "Enter a bet." And so I say, "Even." And it
says, "This kind of launch is configurative. Open the Stanford debugger perspective when
it suspends. Should I open this perspective now?" All right. It looks all big, and nasty,
and you just say, "Yes." Okay.
And it says, "Hey, your program got here. Look at what values you actually have." And
so there's a couple things to look at. Up in this debug window up here, it shows me –
remember when we talked about stack frames. This is what's called the call stack. The
run method called the play Roulette method which called the is winning category method
which is where I'm currently suspended. So it tells you all the functions that are currently
– or the methods that are currently active to get you at your current point.
Over here in the variables window, it actually tells you the value of the variables. So my
bet is even, outcome 13. I say, "Huh? It says the ball lands in ten. I thought that was
supposed to be even, and I was gonna even. What's going on? Over here it tells me that
my outcome, which is the thing that I'm gonna mod or divide by two to see if it's odd or
even is 13. That's not what I got, which means at this point sewage has entered the

system. The value that I thought I should have is not the value that my program actually
has." Okay.
So what am I gonna do? There's two things I'm gonna do. First of all I want to say, "Oh,
I'm in this debugging perspective. How do I get back to the little editor that's my friend?"
You come to the Stanford menu, and you pick switch to editor. Okay. That takes you
back to what you're used to. Notice we're still stopped here, but you're back just in this
editor view.
There's a couple things we're gonna do. First thing we're gonna do is I'm just gonna say,
"Whoa. Stop the program. Something bad is going on." Next thing I'm gonna do is say,
"Hey, my program involves random numbers. So I'm gonna set the seed for my random
number generator, so I can count on always getting the values the same every time." So if
you're debugging with something that involves random numbers, set the seed before you
go into debugging, and that'll guarantee you always get the same numbers. So I set the
seed.
The other thing I'm gonna do is say, "Hey, the number that got printed on the screen was
different than the number that I actually got. So let me look at the code that prints a
number on the screen." So here's spin Roulette wheel. The ball lands then it generates a
random number, and then it returns a random number. What's the problem here? Anyone
want to venture a guess?
Instructor (Mehran Sahami): They're not the same random number, right? It generates
one random number to say, "Hey, the ball lands in some number." That was kind of a
social. And then it says, "Hey, you know what? Yeah, our casino – we just remove that
ball, and we just pick another number randomly to say that's what it really was." Okay.
That's – maybe a lot of fun for the casino, not so much fun for you.
So what we really need to do is inside here we'll have something like spin, and spin is
gonna be whatever we get from the random number generator. Okay. So we'll just say,
"Hey, spin is this random number." And then what we're gonna write is spin over here.
And what we're gonna return is also spin. So we only generate one random number.
Let's save that, and we're like, "Oh, we only generated one random number. That must be
the bug. I must be done. Oh, yeah. Yeah, good times. Good times." So I run my program
again. Do te do – and I get this whole thing, and it says, "Enter betting category." "Even."
"27, you lose." I'm like, "Oh, it must be working." "Even." "15." I'm like, "Oh, yeah, my
program is so good. I'm such good –" yeah. And you think you've found your bug, and
then you realize when you're the vandal, and you're trying to see if that error condition
still exists, "Hey, we found one bug. That was great. That didn't solve this problem."
So you say, "Okay. Back to the drawing board. Let me quit out of here. I'm gonna go, and
set another breakpoint over here. Okay. So let me clear this breakpoint. I'm gonna set

another breakpoint. I'm gonna run it with the debugger. Okay – which is what I didn't do
before." So now I run with the debugger, and it says, "Enter a bet." And I say, "Even."
And it says, "You've stopped here." And so, "Yes. I want to do this debugger
perspective."
And I say, "Hey, the outcome is 27, and so my – if I look at – my bet is not even, right? It
should be odd." So I say, "Oh, that's great. Well, it shouldn't be odd, so that shouldn't
match." There are some tools up here I can use to say, "Step through my program."
There's one in the middle up here if you can look at this line that has sort of this curve to
it. That means step over. And all of these – all these different icons are actually explained
in your debugging handout, but step over is the critical one. It says, "Just execute this line
of code, and go down to the next line of code."
You have two other options. You have step into, which actually makes a function call or
method call if you happen to be in a method, and step return, which says, "Step out of the
current method I'm in." They get a little funky.
So step over is what we're gonna do. So we step over, and odd doesn't execute, and you're
like, "Yeah, odd shouldn't have executed. Even – yeah, my bet is even, right? I know over
here my bet has the value even, so I execute another line. Whoa. What's going on there? I
should've gotten bet was equal to even, and return the fact that my outcome was actually
true that I actually won." What's the problem here?
Instructor (Mehran Sahami): Pardon?
Instructor (Mehran Sahami): Ah, strings. These are strings. I can't use equal equal on
strings, right? It just doesn't work. It doesn't work when you're not looking either. So I
say, "Hey, come back to the editor, and when you want to make some changes – yeah,
instead of checking for equal equals, I actually need to say dot equals here."
As a matter of fact I'm gonna use equals ignore case because that'll make the life of the
user even better. They can either put in odd or even in upper case or lower case. So I'm
just gonna do a little copy, and paste, which is always a dangerous thing to do. Do te do –
so close. Do do – and then for high – and at this point I could go ahead, and save. Oh, it's
still in this perspective. I want to quit out of my program.
And now there's one final thing I'm gonna do here. Let me switch to the editor, and I'm
gonna run one – let me save, and run one last time. And this becomes very subtle. So if I
say, "Hey, I'm gonna bet on odd. Yeah, look I'm winning now because I know that odd

numbers come up. I should've remembered this from last time because I set the seed,
right?" And I keep betting on odd.
And then one interesting thing that happens is zero came up, right. This is something that
may take a while to come up. So I start betting on even because I lost with zero before.
It's gonna take me a while before zero might ever come up again, but I need to be – I
need to persevere. And it's probably not gonna come up in this run. So let me quit this,
and run it again. Do te do – even. And I should get the same sequence of numbers. Even,
even, even – oh, I lost on zero. Right?
There's one subtle bug that's still remains in my code which is for the case for even I not
only need to check for even, I also need to make sure that the value is not equal to zero.
So the other final thing I need to put in here is and and outcome outcome not equal to
zero. Okay. And then my code is actually fixed.
So sometimes it may take me a while to find the actual error in my code through running,
but now you can use the debugger to find it. All right. And if there's any questions I'll
take them after class, and you can pick up your finals –
Student: Thank you.
Instructor (Mehran Sahami): – over from – or the –
Student: Thank you.
Instructor (Mehran Sahami): – midterm exams over from Ben.
[End of Audio]
Duration: 54 minutes

Programming methodology lecture18

More Related Content

Similar to Programming methodology lecture18 (20)

More from NYversity (16)

Recently uploaded (20)

Programming methodology lecture18