Commented Out Code

This post at Visual Studio Magazine by Peter Vogel has invited a lot of contempt (via Rob Conery):

I never delete code — you never know when you might want it back. So I spend a lot of time commenting out code. I do this so often, and mousing up to the menu takes so long, that I’ve memorized the keystroke combination for commenting/uncommenting code. It’s actually one of the few keystroke combinations — other than Undo — that I remember.

Many people assumed that Peter did not use (or know) how to use source control, but as Peter’s replies in the comments section show, he does use version control, but apparently seems to have an aversion to using Diff, possibly because he hasn’t grown comfortable enough exploring how to use source control properly.

I find the lack of knowledge of proper source control to be one of the most common gaps in developers. Even excellent programmers with good command of technology seem to fail when it comes to source control features beyond the basics. I am not sure why this is. Perhaps it is because they think of it as a backup solution (to protect against some hard disk disaster) than something that actively helps them in their development.

To somewhat complicate the issue, there are quite a few different flavors of source control systems out there. There was the horrendous Visual SourceSafe with its file-based system. You have centralized source control systems. I am particularly fond of Sourcegear Vault, a rather inexpensive and competent solution compared to others. And now you have distributed systems such as Git and Mercurial. All of these systems have some similar concepts, but some dramatically different ideas and then their implementations of common concepts can also vary. I have seen some articles from experienced developers trying to relate their prior experience with Subversion to Git and ending up frustrated.

The other practical roadblock to learning source control systems is that the manual approach can sometimes seem easier if you don’t know how things like branching and merging work. Take a backup, use brute force, and so on. Also there is usually one single source control administrator (with centralized source control) who decides how people should use the repository and so everyone in the team learns it that way.

To be optimistic for a minute, the increase in online source control systems like Github, Kiln, Bitbucket and others is putting a dent in this knowledge gap. If you are a programmer who enjoys tinkering at home, there is no excuse to not use one of these tools, especially the ones that offer free private repositories. Even the paid accounts are not costly either. It would be good to work with some friends on a joint project. And bonus – you can now upload your projects to some of these repositories which then automatically deploy them to sites such as AppHarbor and Heroku. I recently did something with AppHarbor and Bitbucket and yes, it is indistinguishable from magic.