How to code: lesson 27

I was reading some code on the Internet today and came across this:

The thing to notice is the hang & symbols in front of the variables, instead of just making things line up. It's a stylistic quirk of the author of this code. It's a good lesson on what not to do.

There is only one important style rule and it is this: make your code look like everyone else's. The question isn't whether it's good or bad, only that it's unusual. Yes, this quick is relatively insignificant, but I point it out is that you should not be tempted, even on the smallest of things.

You see this with the evolution of programmers. In the beginning, their code is quirky as hell. Over time, as they they are exposed to more and more source by others, they start to see how these quirks are irritating, and stop doing them in their own code. The style becomes blander and blander -- but at the same time, the greatness of their construction of the code starts to shine.

When you start writing great code, you'll eventually have to break this rule and do something big and strange. For example, I do this with my "state-machine parsers". It's a programming pattern unfamiliar to most programmers, yet I have to do it because the scalability and performance are huge. Save your quirks for the big things -- exorcise them in the small things.

By the way, I meant this as the only important style rule. It really is. A lot of companies spend a great deal of time, and politically gnashing of teeth among developers, in order to draft style guidelines. This is garbage -- it truly does not matter where you put braces, for example. Experienced coders have to be accustomed to reading various styles anyway. Here's what you should do. Start a program asking anybody who is interested to come in after work in order to draft a new set of style guidelines. Fire everyone who shows up -- they are political animals who are likely deadweight anyway. Then just pick a style guideline at random, like the Linux kernel style doc or the WebKit style. Or, pick no style at all -- your project is going to pull in a lot of open-source with varying styles anyway, so it's pointless trying to make it conform.

BTW, when I invested all my money in a startup consisting of a team of programmers, when my entire life's saving depending on quality code being produced, I imposed this guideline on the team: stop with the nonsense, make it look normal. Each programmer had different styles, but yet the code produced was high quality anyway. It really can work.

C programming: you are teaching it wrong

It's been three decades. There is no longer an excuse for the fail way colleges teach "C programming". Let me help.

Chapter 1: the debugger

C programming starts and ends with the debugger. Before they write a line of code of their own, students need to be comfortable single stepping line-by-line through source, viewing local variables, and dumping memory.

A good first assignment is run the following program, and have the student report the values for 'a' and 'b', which can only be gotten by stepping through the code in a debugger.

int main() {
    int a = rand();
    int b = rand();
    printf("a + b = %d\n", a + b);
    return 0;
}

The "printf()" function is not a debugger. If that's how you debug your code most of the time, you are doing it wrong.

GDB is not an adequate debugger. The reason people rely upon "printf()" is because GDB is too difficult. Even the "TUI" interface is inadequate.

The debugger is not your "last resort", the thing your struggle with when there is no other way to fix a bug. Instead, the debugger is the "first resort": even when your program works correctly, you still use the debugger to step through your code line-by-line, double checking variables, making sure that it's behaving the way you expect.

Code, philosophy, integer overflows

A college professor has created a cool contest to teach people about “integer overflows”. Integer overflows are a common bug that allows hackers to break into computers. Even without hackers, it’s a subtle bug that most C programmers don’t know – but should.

This post discusses my entry to the contest. It’s only of interest to C coding geeks who write parsers.