When you debug code, you shift between two modes, telescopic and infrared. When you’re pinpointing errors, you’re in telescopic mode. When you have no idea where’s the error, only that there’s an error, you’re in infrared mode.
With the advancement of compilers, syntax errors are becoming easier to spot. Chasing down that elusive semicolon is a thing of the past. I learnt to code in a text editor. On a Unix machine using the vi editor no less. I didn’t get syntax errors until I compiled my program. I didn’t get segmentation faults until I ran my program and found out I hadn’t
malloced enough memory for my matrices.
So I was very careful with syntax. Every = sign and == signs. Every ;. Every * for pointers. With monochromatic editors, no squiggly lines and no Intellisense, I developed hawk-like abilities to spot syntax errors before the compiler does. With practice, this extended to even logic errors. The compiler cannot tell you if
int i = 4 + 5;
is correct or this
int i = 4 * 5;
With modern compilers, simple syntax errors are caught easily. Now there’s a different problem, embedded code. Specifically, SQL statements in a string variable. For example, the compiler can’t tell you this is an error
comm.CommandText = "updte WrongTable sett columdesc = you rock' wear user_id='beerkeg'";
You’ll only know something failed when you run the code. Unless you have telescopic debugging skills of course.
Do you know someone who can “feel” a spelling mistake a mile away? Do you know someone who can read paragraphs and paragraphs of text, and then singling out phrases such as “please bare with me”, “just loose that pen” or “that man is stationery”?
They have infrared vision. They see a blurry image and something in the text just doesn’t seem right. Their “spider sense” tingled and they just stop at that error.
Expert programmers do the same thing. Since syntax errors are highly unlikely (because of modern compilers), that leaves subtle coding quirks or logic errors. Somehow, something about this chunk of code doesn’t feel right…
int i=0,sum=0; for(i=1;i<=10;++i); sum+=i;
The inexperienced programmer would be looking at
sum += i; and wondering why
sum doesn't contain the sum of the first ten integers. The expert programmer would be wondering about the use of adequate whitespace, why the
for loop doesn't use curly brackets, and why the
for loop ends with a semicolon... hey, that's the error!
Getting super vision
The thing about telescopic mode is that you get tunnel vision in the extreme case. You blithely ignore large parts of code and focus on a line of code which may not be the source of the error. And you spent half a day wondering why that line of code isn't working. It is. It's the other parts of code that gave the wrong context, and so as a whole, that chunk of code doesn't work.
The thing about infrared mode is that everything's blurry. To make sense of things, you need to have some experience in recognising recognisable stuff. Such as automatically checking the structure of the for loop for the 3 parts (initialiser, terminator and incrementor). The operative word is "automatically". It doesn't do you good wearing infrared goggles in the jungle and spend 5 minutes figuring out that, yes, that bulbous reddish-orangish mass is a human (and not too friendly at that). So it's no good stopping every so often while scanning code.
To get better at debugging, you need to learn to combine both. Use the infrared mode to scan lines of code. Stop briefly when you feel something's not right. Switch to telescopic mode to find out why you don't feel right. If you find any error, go ahead and correct it. If not, switch back to infrared mode and continue scanning.
This gives you the advantages of quick scanning and the tight focus of pinpointing.
Of course, this is terrible if you're just starting out with zero experience, and scanning means you'll miss obvious errors because you're not trained to recognise them. Good news is, the more code you write and debug, the faster and more automatically you can scan, and the more obvious errors look to you. With practice, you'll also recognise good code faster too. This is important because much of what you read will be good code (or at least it'd better be...), and you need to quickly decide that it is good code and continue scanning.
So do you have both telescopic and infrared vision?