DOC PREVIEW
MIT 6 00 - Lecture notes

This preview shows page 1-2-3-4 out of 11 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

MIT OpenCourseWare http://ocw.mit.edu 6.00 Introduction to Computer Science and Programming, Fall 2008 Please use the following citation format: Eric Grimson and John Guttag, 6.00 Introduction to Computer Science and Programming, Fall 2008. (Massachusetts Institute of Technology: MIT OpenCourseWare). http://ocw.mit.edu (accessed MM DD, YYYY). License: Creative Commons Attribution-Noncommercial-Share Alike. Note: Please use the actual date you accessed this material in your citation. For more information about citing these materials or our Terms of Use, visit: http://ocw.mit.edu/termsMIT OpenCourseWare http://ocw.mit.edu 6.00 Introduction to Computer Science and Programming, Fall 2008 Transcript – Lecture 12 The following content is provided under a Creative Commons license. Your support will help MIT OpenCourseWare continue to offer high quality educational resources for free. To make a donation or view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare at ocw.mit.edu. PROFESSOR: I want to take a few minutes at the start of today's lecture to wrap up a few more things about debugging. And then I'll move on to the main event. Just a few small points. First of all, keep in mind that the bug is probably not where you think it is. Because if a bug were there, you'd have already found it. There are some simple things that you should always look at when you're looking for bugs. Reversed order of arguments. You might have a function that takes to floats and you just passed them in the wrong order. You may have noticed that when Professor Grimson and I used examples in class, we were pretty careful how we name our parameters. And I often end up using the same names for the actuals and the formals. And this just helps me not get confused about what order to do things in. Spelling. These are just dumb little things to look for. Did you spell all the identifiers the way you think you did. The problem is, when you read code you see what you expect to see. And if you've typed in l when you should've typed a 1, or a 1 when you should've typed an l, you're likely to miss it. If you've made a mistake with upper and lower case. Things like that. So just be very careful looking at that. Initialization. A very common bug is to initialize a variable. Go through a loop, and then forget to reinitialize it when it needs to be reinitialized again. So it's initialized outside the loop when it should be initialized inside the loop. Or conversely, inside the loop when it should be outside the loop. So look carefully at when variables are being initialized. Object versus value equality. Particularly when you use double equals, are you asking whether you've got the same object or the same value? They mean very different things, as we have seen. Keep track of that. Related to that is aliasing. And you'll see that, by the way, on the problem set that we're posting tomorrow. Where we're going to ask you to just look at some code, that there's some issues there with the fact that you alias things, maybe on purpose, maybe on accident. And by that I mean two different ways to get to the same value, the same object. Frequently that introduces bugs into the program. A particular instance of that is deep versus shallow copy. When you decide to make a copy of something like a list, you have to think hard about are you only copying the top level of the list, but if it's, say, a list that contains a list, are you also getting a new copy of everything it contains? It doesn't matter if it's a list of integers or a list of strings or a list of tuples, but it matters a lot if it's a list of lists. Or a list ofanything that could be mutable. So when you copy, what are you getting? When you copy a dictionary, for example. Think through all of that. And again, a related problem that people run into is side-effects. You call a function and it returns a value, but maybe it, on purpose or on accident, modifies one of the actual parameters. So you could each make a list of things. Every experienced programmer over time develops a personal model of the mistakes they make. I know the kinds of things I get wrong. And so when I'm looking for a bug, I always say, oh, have you done this dumb thing you always do. So be a little bit introspective. Keep track of the mistakes you make. And if your program doesn't work, that should be your first guess. Couple of other hints. Keep a record of what you've tried. People will look at things and they'll come in and that'll talk to a TA, and the TA will say, did you try this? And the person will say, I don't know. That leads you to end up doing the same thing over and over again. This gets back to my main theme of Tuesday, which is be systematic. Know what you've already tried, don't waste your time trying it again. Think about reconsidering your assumptions. A huge one is, are you actually running the code you're looking at in your editor. This is a mistake I make all the time in Python. I sit there in idle, and I edit some code. I then click on the shell, rather than hitting F5, try and run it and say, it's not doing what I thought I should do. And I'll sit there staring at the output, staring at the code, not realizing that that output was not produced by that code. It's a mistake I've learned that I make. It's an easy one to make in Python. Lots of assumptions like that. You thought you knew what the built-in function sort did, method sort did. Well, does it do what you think it does? Does append do what you think it does? Go back and say, alright, I've obviously, some assumption is not right. When you're debugging somebody else's code, debug the code, not the comments. I've often made the mistake of believing the comments somebody wrote in your code about what some function does. Sometimes it's good to believe it. But sometimes you have to read it. Important thing. When it gets really tough, get help. Swallow your pride. Any one of my graduate students will tell you that from time to time I walk into their office and say, do you have a minute? And if they foolishly say yes, I drag them back to my office and say I'm stuck on this bug, what am I doing wrong? And it's amazing what -- well, a, they're smarter than I am which helps. But even if they weren't smarter than I am, just a fresh set of eyes. I've read through the same thing twenty times and I've missed something obvious. Someone who's never seen it before looks at and says, did you really mean to do this? Are


View Full Document

MIT 6 00 - Lecture notes

Download Lecture notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?