Technical Book Club: Code Complete - Programming Conventions
Programming conventions are important, even when if you’re the only developer on a project. When you’re right in the middle of writing some code, you totally understand what you’re doing. You can list off the variables you’re using, how you’re going to put everything together, and most importantly, why you’re doing it. When you come back months later, you’re no longer in that state of mind, and suddenly it seems like the you of three years ago had no idea what they were doing, because now you can’t understand the code at all. Even worse, though, is when you’re working on a project with a team, and your team isn’t following the same conventions. In one of the first projects that I worked on, the programmer would create a variable that was going to be used temporarily for something, and since it was never going to be used outside of the scope of a private method, he would name them something inane, like bleh or blah. I actually ran across a method that used the variable names temp, blah, bleh, blegh, and blagh. One of my tasks as junior developer was to go in to these methods, figure out what they were used for, and name them something that actually made sense.
Luckily, there are some great resources out there to get you started on developing your projects coding standards. I based my standards off of a document put out by Joel Spolsky while he was working with a group of interns on the project that was to be CoPilot. Since then, one of my coworkers clued me in to a great pair of documents on VB and C# coding standards. I don’t agree with everything in them, but I don’t think you’re expected to. It’s mostly used as a starting point to get your own standards rolling.
