~ read.

Project idea: Commit safety for developers

The problem

Programmers are like bad criminals in cop movies. We just like to leave clues everywhere. Most of the time, we work much like writers, from the outside in. Develop an outline, stub out the parts which we might get to, and then fill in the core pieces, followed by the extremities. If you’re lucky you get a quick review and edit and then off to the press.

Often though, we leave in little todo messages like “@todo: Actually write this function” or “@todo: make sure you check for a security hole here”. Or unprofessional error messages like “oops, something didn’t work” or even worse “idiotic user doesn’t know how to read instructions and forgot to use lower case”. And sometimes, I’ve been guilty of leaving debug code in which is there for me to look at what is happening in the code, but should never be accessed by others.

In my 13 years of reading other peoples’ code, I don’t think I’m alone here.

Ever seen “An unexpected error has occurred” or “Oops, shouldn’t have gotten here” in an application… yeah, the dev needed this.

The proposal

An extension to your version control system of choice and/or your continious integration tool which checked code for various patterns and stopped commits from going in, or releases from going out based on those patterns. It would require a little learning, but I could train myself to write “NOCOMMIT: This is a fake error message” where required. And then adding in the debugging commands for different frameworks and languages wouldn’t be too hard.

Just a nice small utility to prevent those accidental screw ups which can be expensive mistakes later on.

If you’d use something like this +1 in the comments or twitter.

I will most likely not be coding this up, but if someone does, please post a link here as a comment.


Originally published at http://www.jacobsingh.name on November 25, 2011.