programming and human factors
by Jeff Atwood
Does this sound familiar?
your program (n): a maze of non-sequiturs littered with clever-clever tricks and irrelevant comments. Compare MY PROGRAM.my program (n): a gem of algorithmic precision, offering the most sublime balance between compact, efficient coding on the one hand, and fully commented legibility for posterity on the other. Compare YOUR PROGRAM.
I first read this in the original 1993 edition of Code Complete. It's quoted from a much earlier book, Stan Kelley-Bootle's The Devil's Dp Dictionary, which was published in 1981. It's still true, more than 25 years later. There's a knee-jerk predisposition to look at code you didn't write, and for various reasons large and small, proclaim it absolute crap. But figuring out who's actually responsible for that crappy code takes some detective work.
The upcoming Visual Studio 2008, or at least the Team System flavor of it, finally delivers a feature I've wanted for years: it can display the code side-by-side with the person who last changed that code.
The last person to change any particular line is identified right there, next to the lines they changed, along with the date and revision number. Hovering over the revision number reveals a tooltip containing any checkin comments associated with that change. Clicking on the revision number brings up the full details dialog for that checkin.
Although I have mixed feelings about source control integration with the IDE, I think this is a fairly compelling argument in favor of it. Sometimes you just want to know who wrote this crap, and having that information directly next to the code in your editor saves many tedious steps of manually tracking down the owner of those particular lines.
This feature is called "annotate" in Team System source control, but it's called "blame" in Subversion and in Vault. So if you're wondering who to blame, now you know. It's all those other developers. Obviously.
I know a lot of people are posting on this so I figured I would put my 2 cents in.
The feature seems to be extremely useful is used correctly. As some people have pointed out you should not use this to see who sucks at programming or had a brain lapse at the point of adding the code, but to find out what they were thinking needed to be changes and why. That way you can get an understanding about why the change is good/bad but not that the person is an idiot. I have never been part of a team of more then 3 people working in the same project, but I can definitely see how this can be useful at least for gaining an understanding of what is the reason for a change if you are not sure. Well that is my 2 cents whether it is the right thinking or the wrong thinking I think it is all a matter of opinion.
As an Emacs user I appreciate the utility of this feature already. While I wont harp on the fact that "we already have that" (that's been pointed out plenty already), I thought I'd mention that I actually find the modification date information more useful than the user attribution.
As mentioned above, Emacs colorizes the annotations so that newer code is highlighted more. This feature is actually quite useful when tracking down bugs as they are more likely to be found in newer code.
Cameron Desautels on February 6, 2010 10:14 PMI was expecting more of a "Make that person change Your Program into My Program"
Useful tool, will check it out when I have time.
Dion Moult on February 6, 2010 10:14 PMFoxyshadis: That's precisely the type of thing you should be writing comments for!
I've got all sorts of gems littered throughout the current project, such as:
// The row version must be retrieved with a different DataContext from the one used to attach, otherwise a "key already exists" exception will be thrown when SubmitChanges is called.
or about 50 of these...
// This setter is here for XML serialization. The property cannot actually be changed.
Aaron G on February 6, 2010 10:14 PMSurely it is handy to know who wrote what. But blaming is not as good as making things right in the first place.
Don on February 6, 2010 10:14 PMProfessionals are not having fun, they are serious.
"A clever person solves a problem. A wise person avoids it." -Einstein
But isn't it most fun, when there is no crap code at all? When you are released from the heavy burden of decrypting and fixing mysterious looking program parts, you can lean back and breath deep the nice spring air. When you are relaxed you perform better and you are free as a clever fox for new and interesting adventures in the always so wonderful world of software.
Don on February 6, 2010 10:14 PMMany people here are missing the point of this feature. Your source control system must allow you to select a particular line of code from the current version, and show you the commits that contributed to that line of code. ClearCase falls woefully short of this - as it does for so many vital features and as usual, the dedicated crowd of ClearCase followers are blissfully ignorant of its inadequacies.
Alex Worden on July 30, 2010 9:49 AMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |