Additional profile information on Alfred Thompson at Google+
When ever programming teachers get together one of the debates that often starts up is between using a built-in debugger or using other debugging tools - most commonly extra print/display statements. It is an interesting debate and can get quite religious at times. I have been a long fan of debuggers ever since I used ODT (Octal Debugging Tool) on a PDP-8 many years ago in college. ODT let me examine the contents of memory and many of the computer's registers while debugging assembly language programs. The values were displayed in binary coded octal by the way.
Debuggers have come a long way since then to say the least. Today it is easy to set break points, track the changes in values in variables and intimately watch expressions as they are executed. I do believe that one can learn a lot just by following the execution in code in the debugger.
One of the problems with debuggers though is that sometimes the extra data and process that code goes through in the debugger changes its nature. That means that some bugs that show up easily without the debugger go away inside the debugger. And it seem, though rarely in my experience, that things go the other way as well. For that reason it is always good to have other options. Multiple tools in the tool box is the way to go.
The other technique that has been used since the beginning of programming is logging data during execution using output statements either to the system console or to a log file. This can be a very valuable tool especially when there is no easy way to determine how many iterations of a loop (for example) have to take place before the bug occurs. Single stepping through a loop 1,000 times is tedious. There are times when the program will crash in the debugger and one can get some information but all too often one can't get enough. being able to look through a log file can save a lot of time. There is an art to setting these statements and it is something people should be taught.
But there is more to debugging than running things live in the debugger or tracking the flow of code though a complex set of loops and methods. There is the matter of unexpected errors. Now in theory one should test every possibility but in practice that often turns out to be impossible. One simple operating system I worked on over 25 years ago was complex enough that it was estimated that testing every code path in every possibility would take over 300 years. I think that the complexity of operating software has more than kept up with the speed of CPUs so I suspect that sort of math to still be that way.
So to me adding debugging tools and techniques means making sure that when something does go wrong people have enough information to figure out what is going on. Error handling code should provide more information than just the routine that crashed and an operating system dump message. The values of important variables for example can be very useful. Things like loop counters are particularly valuable.
Additional debugging statements that can be set on or off without recompilation can be particularly valuable. Often one can set up their debugging statements to execute or not based on some external setting. More than a few times this has made the difference between a problem being solved quickly and taking a very long time. This is especially useful as a common way to deal with bad data. If the program keeps crashing turning on the debugging output and rerunning the data often pinpoints the bad data more quickly and accurately than going through it by hand ever could.
No matter how good a coder one is there are always going to be bugs to find. Perhaps not in your code but when you are assigned to debug code written by someone else having some debugging techniques in your tool kit can be a life saver.
This is the sixteenth of a series of posts based on the book Programming Proverbs by Henry Ledgard. The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there. Comments on this "proverb" are of course very welcome here.
Kalid Azad sent me an email about his online calculator site called InstaCalc and it is really impressive. It's the kind of project that people have talked about for years - one can type equations into the program and it just calculates the results. You can enter something like 5% X 100 and get 20 as your answer. Or mix Hex, Binary, Octal and Decimal in the same formula - 0x1a + 0b1001 +0o10 - 1 and get 42.
You can save and share your mini-programs with others as well. There are a number of saved calculations there already. Try out this sample saved calculation page that demonstrates hex, octal and binary calculations. Or this one on doing a home loan calculation.
I can see this being useful in a lot of ways - getting an understanding of variables and different number systems being only the most obvious.
The Visual Basic team blog has had quite a run of great posts lately. The topics have been very interesting to me on several levels but one that really hits home to me is that they are very approachable. By that I mean one doesn't have to be a professional developer or some sort of advanced graduate student to understand them. A lot of them are, you should excuse the pub, pretty basic.
Lisa Feigenbaum has a post on customizing your menus in Visual Studio for example. And two on using shortcut keys that you may find useful. (here and here) Lisa really knows what's in the IDE and I have learned a lot from her posts.
Matt Gertz has a nine part series on programming at game of Euchre. That's a card game BTW. I knew a lot of people who played it in college but never learned it myself. Be that as it may, Matt's series is a great way to learn how to write a card game program in Visual Basic.
Recently Matt started a two part series on overloading operators using matrix operations as the sample/case study. The first in the series is here. Sample code is provided.
And that is just a sample of what is going on over there. If you are teaching (or learning) Visual basic that is a blog you will want to follow. And if you are looking for some projects to keep your advanced students busy or for them to use as semester end projects some of Matt's posts may give them some ideas and a kick start in the right direction.