Additional profile information on Alfred Thompson at Google+
We don’t teach students how to read code. Actually we don’t event teach them that they should read code for the most part. The closest we get is sample code in textbooks, demos, and for AP CS teachers the case study. Even there I think we could do more. One of the great learning experiences of my early learning career involved reading some code. My professor handed me a deck of cards (yes this was some time ago.) He explained that they had purchased this set of functions to help enable graphics programming but somewhere along the line the documentation had been lost making this code unusable. There were almost no comments in the code either. My task was to figure out the code and create some documentation so that other people could use these routines. With all the enthusiasm and confidence of youth I jumped in with gusto. It took a while but I accomplished the task. In the process I learned a lot about both figuring out code and using graphics functions. Both served me well over the years. I still think about that now and again wondering if that sort of thing could be globally useful in education. Or is it just mean?
I still enjoy reading and figuring out other people’s code. In some ways that, especially when debugging is involved, is more fun for me than writing code from scratch. I’ve never really organized my thoughts about reading code before but I’ve been thinking about it lately and thought I’d put it down so you all could tell me how wrong I am. Or at least tell me what else you do when studying code that is new to you.
I like to read code on paper. Yes old fashioned and kills trees but it lets you look at more code at one time than you can see on a screen. I know that there is some discussion that any code that doesn’t fit on one screen should be broken up into smaller pieces and to some extent I agree. On the other hand some things don’t fit on one screen and more then that often you can benefit from more context than one method on one screen. Also I like to draw lines and write notes and that is easier on paper.
In he early days code was often “ugly” with no indentation or helpful formatting. In fact we used to have special software called “prettyprint” programs that would reformat code by adding indentation, consistent use of white space and “punctuation.” I especially remember using software like this on PASCAL programs when I was teaching high school. The need for this sort of thing is less today than it used to be. IDEs like Visual Studio for example will automatically format code and even include helpful color coding. These things make looking at code, on line or on paper, a lot easier. Reading poorly formatted code is harder than you want it to be so if your code is not well formatted then fixing that is a great first step.
Next I like to look at variables. I like to understand the names, especially any coding standards that are being used, and what they mean. Knowing that a variable is an integer as opposed to a double is important. Making sure that coding conventions (do integer variables start with an “I”) and being followed (is a variable a double but its name suggests an integer) is a good place to look for logic or runtime errors. Keeping an awareness of scope of variables is also important. Comments on variables and throughout the program can of course be very helpful. My attitude about comments is “trust but verify.” That is to say that I try to confirm that the comments describe the code that they say they describe. If they fit – great. If they are wrong – fix them.
I like to draw lines to highlight things like the beginning and end of a loop, a module, or the actions inside a decision structure. The spacing along may be enough for some but I like that line down the side of the page. It helps me visualize the scope and the nesting of statements and variable scope. This also helps me to study the code to make sure the start and end are logical and correct. Once you have all the scopes figured out you can start from the inside and work out or from the outside and work in. In practice, if the code is at all complex, you may have to read it both ways. Take notes of what is going on. It helps.
Equations require a close look. One has to understand both what the formula is supposed to do but that the variable types work the way the programmer intended. There is no magic “do what I mean” instruction. All too often the computer follows its own consistent logic when a programmer was hoping (or miss-assuming) some different way of doing things. It’s also important that the values that are returned are of the type that the method says will be returned. A reason that I find paper useful is to double check parameters between where a method is called and where it is created. Again modern IDEs can make that easier for you. While reading code in the IDE IntelliSense in Visual Studio or other autocompletion tools can make checking a lot easier without bouncing around the file. So a mix of online and offline reading can be very useful. Use the tool that makes the most sense at the time.
The big gun in reading code can be a debugger. Single stepping through running code, assuming you are trying to understand code that works, can teach you a lot about what paths are taken and show you where things are not going where you think they are going. This is a lot easier today with modern IDEs compared to reading binary code in light switches back in the day. Today anyone can run a debugger. And more people should!
So that is the basics. I’m sure I’m missing things that I do without really thinking about it. What advice do you have for someone reading code?
Capturing students' interest and making concepts come alive is an educator's greatest challenge! Kinect™ for Xbox 360® can help get students engaged and inspired with immersive experiences.
è Try Kinect at your K-12 School
The Kinect Trial Program gives K-12 institutions the opportunity to try Kinect™ for Xbox 360® at no charge and see first-hand how Kinect can help enhance traditional lesson plans, physical education, school communications and after-school programs. The Kinect Trial Program provides usage of one or more Kinect in Education Trial Kits for a limited period of time. Each Trial Kit includes:
- Xbox 360 Kinect 250GB Bundle (Xbox 360 console, Kinect Sensor, Controller, cables – everything you need)
- (5) Kinect games: Kinect Adventures, Kinect Body & Brain, Kinect Sports Season , Kinect Sports Season 2, Kinect YooStar 2 (middle & high school only)
- Easy Instructions and checklists to help you get started
- 200+ Kinect in Education Activity Plans
- Posters and stickers for your school and students
- To-parent flier and family discount for Microsoft Store
- A pre-paid, return air bill for the Kinect Trial Kit
- Short survey to provide feedback about your experience
If you would like to request a free trial, simply complete this online Kinect Trial Request Form and we will follow up directly to schedule your trial. For questions about the Kinect Trial Program, contact eduKinect@microsoft.com.
Learn more about Kinect in Education
See how Steuart Weller Elementary has used Kinect to engage students in the classroom, P.E., special education and more.
Visit www.microsoft.com/kinectineducation for more information, discounts for academic institutions and how to buy,
I’ve long had mixed feelings about recursion. (I’ve written about recursion several times in this blog.) In one post, Recursion Early, Recursion Late, I wrote about the suggestion that recursion be dropped from a first programming or computer science course. In another post I asked if it should be added to a list of Four Key Concepts of Computer Programming. Well recently over dinner a colleague stated that students learn recursion better if they learn it before they learn loops. A second colleague responded that they had seen the same thing. Apparently they both feel that students have to unlearn something if they learn loops before recursion. I have to wonder if that is the reason I struggled with recursion as a student.
Honestly I am not a fan of using recursion for looping. Recursion feels like a resource intensive way to do things that don’t really require it. On the other hand educators I know who start with functional languages such as Scheme tell me that recursion is very natural and easy to learn/use if taught first. This is probably true – that recursion is more natural in functional languages. I remember a time when “does the language support recursion” was a reasonable question that was often answered in the negative. So there was a time when many of us didn’t see recursion as all that practical. I can’t imagine a language today getting far without support for recursion.
Which brings me back to where I started. Recursion has a lot of similarity with “normal” loops. One needs to set the initial state(s), do some sort of work, and setup an properly terminating condition and test. Recursive routines without a clean and clear end state to start the unrolling create huge memory problems and stack overflows. Poorly constructed loops generally either terminate early or never terminate at all. Either way you get an interesting debugging problem. So given all that perhaps it does make sense to start with recursion.
One final note, the colleague who started this conversation told us that she had taught this course twice in a row. The first group of students really took to recursion and tended to use it when other sorts of loops would be as easy or easier to use. The second group complained asking why they had to learn the hard way (recursion) first when loops were so much easier. So you never know how students are going to respond.
So do you teach recursive loops first or some other types of loops first? What works for you?