11# Debugging Lecture 1
22
33Nobody writes programs that are correct the first time around. Today we'll learn
4- about debugging: the act of finding and fixing bugs in your code. In your career
5- as a programmer you'll discover and fix many bugs and you'll debug code by other
6- programmers. Learning how to debug a program is an essential skill for any
7- programmer. Throughout the entire curriculum you will get homework/exercises
8- that require you to fix buggy programs.
4+ about debugging: the act of finding and fixing problems in your code. In your
5+ career as a programmer you'll discover and fix many problems and you'll debug
6+ code by other programmers. Learning how to debug a program is an essential skill
7+ for any programmer.
98
10- What is a bug? A bug lets a program do something it was not intended to do. But
11- that definition is rather vague. Let's break it down. Following
12- Zeller<sup >1</sup > a bug consist of three distinct parts:
9+ These problems are generally referred to as bugs, but why do we call them bugs?
10+ Well, the reason is probably because Grace Hopper, one of the famous and one of
11+ the first programmers, frequently recounted a story where in 1945 a real moth was
12+ found in one of the computers. The people who found the moth kept the insect and
13+ added it to the logbook with the subtext: "First actual case of bug being
14+ found." The term stuck around and we still use it today to refer to problems in
15+ code.
1316
14- 1 . A ** defect ** - "a piece of code that can cause an infection."< sup >1</ sup >
17+ ![ A real bug ] ( ./images/first-bug.jpg )
1518
16- * We can think of a ** defect ** as the source of a disease. *
19+ * "First actual case of bug being found" * : joy :
1720
18- 2 . An ** infection** - "a program state that is different from the programmer's
19- intention."<sup >1</sup >
21+ ## Becoming Sherlock Holmes
2022
21- * From the source of the disease an ** infection ** takes place. Someone will take
22- ill and in turn that person will make more and more people ill and so on. *
23+ Take off your programmer hats and put on your Sherlock hat cause we're going to
24+ treat our code as a crime scene.
2325
24- 3 . A ** failure** - "externally observable effect of faulty program behavior
25- caused by the infection."<sup >1</sup >
26+ Let's say someone was murdered and Sherlock Holmes was called to solve the
27+ murder. Holmes enters the crime scene and will first look at the victim to see
28+ what happened. Quite quickly though he will start looking for objects that might
29+ have been used to commit this crime, and the objects that were used to prepare
30+ it. From this evidence he will try to imagine what exactly happened. This
31+ process is called deduction, taking one thing and thinking about what it
32+ logically implies: if a gun was found near the crime scene and a bullet of the
33+ gun was found on the victim we can logically conclude the gun was the murder
34+ weapon.
2635
27- * When we notice someone took ill we know that there has been an infection and
28- that there must have been a source somewhere. *
36+ We're gonna do exactly the same! Except we're not gonna murder anyone and our
37+ crime scene is not in the real world but in the virtual world of code.
2938
3039## Hello wordl
3140
32- Let's look at this program. It has a defect in it:
41+ Let's look at this program. It has a bug in it:
3342
3443``` js
3544// This program should log `hackyourfuture`
@@ -44,16 +53,12 @@ console.log(result);
4453
4554## Reading failures
4655
47- To debug our code we have to become a bit like Sherlock Holmes. We have to
48- question everything. Our code is wrong and we can't trust it anymore. Be
49- suspicious while debugging, it helps you get into the right mindset.
50-
5156Debugging always starts by reading either some failure message or look at
5257something you didn't expect. Now, what a lot of people do is throw their hands
5358in the air and say: "aahhhh, it's not working!". Don't do that. Something is not
5459working, you don't know what, but you're gonna find out. Most likely most of
5560your code is perfectly fine, but you just made a mistake somewhere. Reading the
56- error is the absolute first step and the first clue to where your defect might
61+ error is the absolute first step and the first clue to where your bug might
5762be hiding.
5863
5964Let's run our program to see what it does:
@@ -64,27 +69,18 @@ console.log(result); // the observable failure: `hackyourfutureundefined`
6469
6570Quite simply we expect ` hackyourfuture ` to be logged but instead we got
6671` hackyourfutureundefined ` . This is our failure, now we need start looking
67- at where our program got infected .
72+ at where the code is that caused this problem .
6873
69- ## Tracking infections
74+ ## Inspecting state
7075
71- A defect will always result in one or multiple infections. Remember that an
72- infection is some program state that is different from what we intended it to
73- be. The program state (or state) consists of all the variables and
74- their contents.
76+ A bug will always result in unexpected program state.Remember that the program
77+ state (or state) consists of all the variables and their contents.
7578
76- ** Questions:**
77- 1 . In the code we're currently debugging, what is the state?
78- 2 . Why would we want to look at the state? How does that help us get closer to
79- the defect?
80- 3 . We can look at the state using ` console.log ` . Where should we write a
81- ` console.log ` line?
82- 4 . What state should we log?
83- 5 . What is going to be the output of our ` console.log ` line?
79+ ** Question:** What state should we log and where do we put the ` console.log ` lines?
8480
85- To find the defect we first need to look at the state to see what got infected.
86- To do this we add a ` console.log ` line to our code where we let the program
87- write down our state every time we do a lookup in the ` elements ` array.
81+ To find the bug we first need to look at the state to see what's off. To do this
82+ we add a ` console.log ` line to our code where we let the program write down our
83+ state every time we do a lookup in the ` elements ` array.
8884
8985``` js
9086result += elements[index];
@@ -103,68 +99,30 @@ hackyourfutureundefined
10399
104100We see that at index ` 3 ` when we do a lookup in our ` elements ` array. The
105101element isn't there and javascript gives us the ` undefined ` value instead.
102+ If we know that ` index ` has the wrong value we can look at the code that
103+ affects ` index ` .
106104
107- ** Question:** Based on this information where do you think the first infection
108- happened?
109-
110- ` index++ ` is where the infection happens as a result of our defect, whatever
111- that defect may be.
112-
113- ** Question:** What other state got infected?
105+ ** Question:** What other state got affected by our bug?
114106
115107Because we add ` undefined ` (through ` result += elements[index] ` ) to ` result ` ,
116- the ` result ` variable is now infected as well.
108+ the ` result ` variable is now affected as well.
117109
118- ## Finding and fixing a defect
110+ ## Finding and fixing a bug
119111
120- Why would ` index ` become ` 3 ` in the first place? If we can answer that question
121- we get closer to the defect. Let's look at what the ` for ` loop does:
112+ Ofcourse our ` for ` loop is the code messing with the ` index ` and we can easily
113+ see the condition is wrong and should be ` index < elements.length ` instead.
122114
123115``` js
124116for (let index = 0 ; index <= elements .length ; index++ )
125117```
126118
127- A ` for ` loop is a very useful construct but also quite complicated. We can think
128- of a ` for ` loop as a specific kind of ` while ` loop.
129-
130- ** Question:** how could we write the ` for ` loop in terms of a ` while ` loop?
131-
132- ``` js
133- let index = 0 ;
134- while (index <= elements .length ) {
135- result += elements[index];
136- index = index + 1 ; // Same as index++
137- }
138- ```
139-
140- The line ` while(index <= elements.length) ` prevents this program from looping
141- infinitely until the end of time and instead only runs until ` index ` reaches a
142- certain value. We know that when ` index ` is ` 3 ` it's infected.
143-
144- ** Question:** in what other place(s) do we find the number ` 3 ` ?
145-
146- We also know that ` elements.length ` is also ` 3 ` because it contains three
147- elements. We can now deduce that our defect is in the ` index <= elements.length `
148- statement and in fact it should have been:
149-
150- ``` js
151- index < elements .length
152- ```
153-
154- ** Question:** what would the output of the following program be? Is there a bug?
155- If so, what's the defect?
156-
157- ``` js
158- // This program should print:
159- // hackyourfuture
160-
161- let elements = [" hack" " your" " future"
162- let result = " "
163- for (let index = 1 ; index < elements .length ; index++ ) {
164- result += elements[index];
165- }
166- console .log (result);
167- ```
119+ With this simple example you can see that even though the code is small and the
120+ bug is quite obvious there's a difference from where we observe a failure in our
121+ program and the code that caused it. It's important to always remember this,
122+ with more complex bugs there's often a bigger distance (in code) between the
123+ code that caused the failure and the code that has a bug in it. The code that
124+ caused the failure can often be perfectly fine, but the code that has a bug
125+ never is.
168126
169127* Background: These types of bugs are called off-by-one bugs and are in fact
170128quite common. In our first buggy program we were expecting the value ` 3 ` to
@@ -173,21 +131,28 @@ counting at `0`. The 3rd element corresponds to the `index` variable being equal
173131to ` 2 ` .*
174132
175133** Question:** if there has never been a failure in your program does that mean
176- that there are no defects in it? Motivate your answer.
134+ that there are no bugs in it? Motivate your answer.
177135
178136## Summary
179137
180138We covered a lot of ground in this lecture, introducing many new concepts. To
181139summarize:
182140
1831411 . You learned that bugs are part of a programmer's life.
184- 2 . You learned that a bug consists of three distinct parts:
185- 1 . A defect.
186- 2 . One or multiple infections.
187- 3 . An observable failure.
188- 3 . You learned how to use ` console.log ` to look for infections to lead you to
189- the defect.
142+ 2 . You learned that a bug can cause a failure in your program.
143+ 3 . You learned how to use ` console.log ` to look at the program state to find the bug.
1901444 . But most of all: don't panic! :)
191145
192- <sup >1</sup > Zeller, Andreas - Why Programs Fail, Second Edition: A Guide to
193- Systematic Debugging (2009)
146+ ## Notes
147+
148+ - Foute html code fixen, diff checker
149+ - Debugger behandelen
150+ - Wanneer geven we de les? week 4 javascript (DOM manipulation challenge, array strings, clicks)
151+ - Iets debuggen wat lijkt op het huiswerk
152+ - Debuggen incorporeren in het curriculum
153+ - Linkje naar debugging in de week 4 javascript MAKEME, en later nog een keer.
154+ - Sessie wanneer ze met async requests aan de gang gaan
155+ - Meest waardevol: code samen schrijven en daarna de code aan ze geven om de bugs op te lossen
156+ - samen één bug oplossen
157+ - laat ze zelf bugs oplossen (er zitten nog 5-10 overige bugs in)
158+ - groepshuiswerk (in teams van twee, het team die het als eerst oplost wint een prijs)
0 commit comments