notes and rants : General Coding

Debugging 100

alanpa — Mon, 02 Oct 2006 23:35:42 GMT

Universities typically title their introductory courses XYZ 101: Introduction to XYZ. Often, the 101 courses require that students have some basis of knowledge in the area (e.g. pre-algebra for a math 101 course, or some level of writing skills for an English 101 course). Where I went to school, these "pre-intro" courses were "100" courses - e.g. Math 100: Pre-Algebra.

I was recently asked to prepare a short course on debugging for a group of recent college graduates. The catch is, that none of them graduated with a computer science degree. They know some programming, but probably (imo) not enough for me to dive right into a laundry list of debugging tools and techniques.

As I was thinking about this, I realized that a lot of developers are too dependent on the tools. I have observed dozens (if not hundreds) of debugging sessions where developers stared at the code (or assembly) in the debugger looking for a hidden clue, or stepped meticulously through the code, only to miss the moment when their precious variable changed values. I've worked with developers who refused to look at a bug (or even think about it) unless it was trapped in the debugger. Debugging tools are one part of debugging, but I decided that I will talk about the other parts of debugging.

Simply put, debugging == isolating the problem. That means that to improve debugging skills, you need to improve skills on problem isolation. If your car won't start, what do you do? You could outsource (call a mechanic), or you could debug. If you decide to figure out why your car isn't starting, you are going to try to isolate the problem. You will want to examine the symptoms (is the engine turning over or not), the environment (is it cold, hot, do I smell gas, do I have gas), and historical variables (when was the last time it started, has this problem occurred before?). Once you've thought about these things, then you should bust out the appropriate set of tools (jumper cables, gas, oil, tire iron, ...) to help narrow things down. To me, these steps make perfect sense when thinking about a car that won't start, but I see developers (including test developers) ignore this when trying to track down a bug.

Tags: Debugging, Software Quality

A shell only a geek could love

alanpa — Fri, 11 Aug 2006 00:04:00 GMT

There’s a bunch of stuff not about testing that I wanted to share or comment on. This is the first of two or three or four non-testing posts on my mind.

I recently installed Powershell (formerly known as monad). I played with the betas, but never really used it. The short story is that after using it for a few weeks, now I love the dang thing. I’m a self professed command line junky, and not only does it do everything that my old hopped up command prompt did, but it does about a million other things.

Note: Many years ago, I was an avid 4dos user, but for some reason, I never made the transition to 4nt. Now that I think about it, the main reason may have been that I had a licensed copy of 4dos, but was too cheap to pay 75 bucks for 4nt. I missed the ultra customization that these shells allowed, but cmd.exe was fine for most of what I needed to do to be productive.

Pictures (or pseudo pictures) are worth hundreds of (if not nearly a thousand) words, so let me just say (and to paraphrase Joel), can your command shell do this?

[C:\]

>pushd HKCU:

[HKCU:\]

+>cd \Software\Microsoft\Windows

[HKCU:\Software\Microsoft\Windows]

+>dir

Hive:

HKEY_CURRENT_USER\Software\Microsoft\Windows

SKC VC Name Property

--- -- ---- --------

33 0 CurrentVersion {}

2 1 Shell {BagMRU Size}

4 2 ShellNoRoam {(default), BagMRU Size}

[C:\]

>$a = 1,3,5,2,4

[C:\]

>$a

[C:\]

>$a.GetType()

IsPublic IsSerial Name BaseType

-------- -------- ---- --------

True True Object[] System.Array

[C:\]

>$a | sort

or even

[C:\]

>$first = "alan"

[C:\]

>$last = "page"

[C:\]

>$fullname = $first + " " + $last

[C:\]

>$fullname

alan page

[C:\]

>$fullname.ToUpper()

ALAN PAGE

[C:\]

Not the best examples, but pretty cool nonetheless.

Of course, there’s not a ton of practical use on my current team (I don't get to do very much coding or building these days), but I’ve already found dozens of ways to make my life easier with powershell.

(I know that there are roughly a gazillion other powershell raves floating arount the intranets, but I couldn't resist adding my own)

The experts know even more.

Curly brace positioning redux.

alanpa — Mon, 14 Feb 2005 14:46:00 GMT

I can't say I didn't enjoy the conversations around this question - it's just that I only got two comments on my actual question. People that want history can read the previous post - for all others (including any who want to "re-comment"), the question is simply this:

What do you think of this brace placement style. For the sake of this discussion, I don't want to hear about other styles you like, I just would like your comments on this particular example (clear enough?).

if (var < max)

{
DoSomething();

DoSomethingElse();
}

To be clear, I do really enjoy conversations about this highly controversial subject - I just want to target my answers in this particular case.

Quick survey on curly brace positioning

alanpa — Sun, 13 Feb 2005 04:19:00 GMT

I absolutely don't want to get into a debate over whether it is better to put curly braces on their own line or not, but I do have a question on indentation I'd like to throw at the masses (ok - all 7 of you).

Generally, the curly brace debate boils down to these two examples:

if (var < max) {
DoSomething();
}

vs.

if (var < max)

{
DoSomething();
}

I recently came across a body of code that uses a variation on the second method – but to me is far less readable. Am I missing something? Does anyone else favor this format?

if (var < max)

    {
    DoSomething();
    }