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.
Perforce has an even niftier feature: time lapse view. Basically the same thing, but you move a slider back and forth in time, to see how the file looked in the past (and who was responsible for those previous revisions, too.)
[edit http://www.perforce.com/perforce/products/tours/p4v/images/p4v_time_lapse_view_7.gif ]
Michael Gebis on November 6, 2007 10:45 AMWumpus,
Note that the svn blame command also has an alias: praise. I prefer blame, naturally. Praise is for hippies.
Beech on November 6, 2007 10:55 AMIt's interesting when you write some piece of code in an application, and then go back to it 6 months or a year later. It's your own code, but you might still ask "Who the hell wrote this crap?"
It might be something that you, and the team, all thought was ok and it made it into the final version. Yet, given some time it's inevitable that you learn things that make you stare in consternation at your old code.
kettch on November 6, 2007 11:01 AMThis feature is already some time available for TFS and VS 2005 as a Powertoy, even for the command line according to this: http://blogs.msdn.com/bharry/archive/2006/09/07/744993.aspx
Qma on November 6, 2007 11:36 AM"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."
Actually, this has nothing to do with VS 2008. It is available in VS 2005 Team System as well, so I would rather say this is a Team System feature
ds on November 6, 2007 11:37 AMSource control systems such as SCCS and ClearCase have stored this information for years, although this is a nicer interface.
However, I've seen that the biggest culprit is usually 'guest' or 'administrator', or even worse, 'test', since control over user logins has never been that strong.
This reminds me of my Subversion plugin for Delphi:
http://tondrej.blogspot.com/2006/07/blame.html
There's a saying that goes like this: "Code is like shit - it only smells if it is not yours".
Alex Railean on November 6, 2007 11:50 AMI quickly read over the comments, and I may have missed something, but to my knowledge no one brought up an extremely obvious point. Everyone is talking about mercurial, git, vim, emacs, blah blah tools tools, but nothing about the obvious human aspect to these types of features.
You are _blaming_ another coder for something they have written. As illustrated by the very first couple sentences in the post, you are all ready inclined to think you are right, and they are wrong. So now you've turned yourself into one of those developers. The one that is looking for WHO did something instead of WHY they did it. What is important to the success of a project has very little to do with who wrote it. Take for instance the screenshot you show above. Are you really trying to figure out if Sally sucks at programming, or are you trying to figure out why she added the regular expression?
Unless it is your job to figure out who to fire and who to hire, stop trying to make it your job to figure out who to fire and who to hire. I understand maybe you'd like to go talk to Sally and ask her.. but then that is an issue in your commit messages, not your IDE. In open source work, there generally will be someone who becomes poisonous to your project and you will have to ask them to leave even if they are a major contributor. This does not mean you need to constantly think about who owns what line of code. I think this is something that XP warns against, and I might actually agree with.
http://www.extremeprogramming.org/rules/collective.html
I've rambled quite a bit here, but I think my point is straight forward. Don't blame specific members of your team for their code, understand why anyone would have written the code.
Jeff Mickey on November 7, 2007 1:04 AMThe 'blame' tool isn't always so useful. At my current company, we do a lot of work on branches that gets merged into trunk. It's not always the same person who wrote the code that performs the merge, so you end up having to delve into the full history in any case...
Ant on November 7, 2007 1:23 AMI partially disagree, as the VCS can only resolve conflicts to the point where coder intervention is required. If the time comes and you have to resolve conflicts manually and the IDE just shows you ".rxxx" and ".mine" blocks you can loose precious time.
Oh yes, I definitely agree with that part.
Masklinn on November 7, 2007 1:24 AMIt looks like a really nice feature however the tradeoff between the speed hit when starting up a project plus maintenance issues using SC bound projects isn't in my opinion worth it (I’m connected to SC over the internet). I can do the same just looking up change history albeit slower and in a less flashy interface.
I use Subversion, Tortoisesvn and VisualSVN for my source control needs and together they’re simply brilliant. I coordinate an open source outlook style list control hosted on Codeplex and found using TFS over the internet to be extremely slow with annoying with credential dialogs popping up every time I opened a project. Then I found SvnBridge which allowed me to us Tortoisesvn and VisualSVN against a TFS backend.
Having used both systems Subversion shines for internet based connections whereas TFS seems to be tweaked for LAN type collaboration. I’m talking here only about the source control side of things of course as TFS also has loads of features to do with testing / work item tracking etc…
Regards
Lee
"It's interesting when you write some piece of code in an application, and then go back to it 6 months or a year later. It's your own code, but you might still ask "Who the hell wrote this crap?""
Oh yeah. I have that pattern ;)
Bill de hOra on November 7, 2007 2:12 AMSince you already know who to blame (the other developers), isn't this feature unnecessary? Or perhaps Microsoft needed a way to keep track of all the bad coders, like a payroll project.
L. A. Karlsen on November 7, 2007 2:15 AMNow if everybody edits the code as administrator , we are back to our sleuthing ways of finding the culprit. Oh well ...
Hmmm on November 7, 2007 2:27 AMre: Ant
Yes I've noticed the same thing - if you branch and merge for bits of development, all this fine-grained info is harder to keep track of. Makes me wonder about whether to bother with branches.
"I'd like to know if people that write such comments are writing 'new' stuff themselves?"
Well, once I wondered how an editor could automatically rename local variables or members (with looking for new and old shadowing etc.). That was about 1990, but the moment just passed by...
"If not, do they constantly write themselves e-mail complaining their work is not original?"
When someone just has discovered the wheel, I don't need to have actually invented it for a minor correction. As we all know, microsoft invented the hierarchical filesystem, the windowing system, you name it... Aprops: 'cvs annotate', but you can blame emacs for only showing the output in a separate buffer, not as decoration to the file buffer.
Andreas Krey on November 7, 2007 3:40 AMNormally if I saw some checkin for "Administrator", I'd assume that he is merging branches, or if the date is really old, this is the initial import into source control.
Joshua on November 7, 2007 4:01 AMCVS annotate command was available in Emacs back during the Jurassic. Here is the link to the Emacs manual:
http://www.delorie.com/gnu/docs/emacs/emacs_137.html
I would propose a new law - "Any feature of a GUI based IDE has been available in Emacs for at least 10 years"....
...richie
Richie Bielak on November 7, 2007 4:36 AMWho wrote this crap? The answer is right here http://www.codinghorror.com/blog/archives/000878.html
JosephCooney on November 7, 2007 4:37 AMSince you already know who to blame (the other developers), isn't this feature unnecessary?
You specifically want to know who to hit with the nerf gun ;). Or who has to pay a dollar because s/he broke the build.
Rob Janssen on November 7, 2007 4:51 AMRubbish. Ford was founded 32 years after Benz Cie. They just stole the idea of the the 'car' concept and made cheap knock-offs. Everyone knows Mercedes are better designed and never go wrong...
Pete Kirkham on November 7, 2007 4:54 AMkettch, what's real fun is what you have the "who wrote this junk" reaction, realize it was you, sigh and start recoding it, only to remember after a few hours that you're working with a completely broken component/API and wrote it that way because you have to watch out for and pick up after all of their mistakes.
Foxyshadis on November 7, 2007 4:59 AMWho wrote THIS crap : http://pastie.caboo.se/111566 !!!
p4bl0 on November 7, 2007 5:07 AMC.R.A.P. actually works as an acronym for "Code Written by Another Programmer".
Only when spoken however.
James on November 7, 2007 5:14 AMIf this feature requires using VSS, which I assume it's a safe assumption that it does, then it's useless to me because you couldn't pay me to switch from SVN to VSS.
I love ms's tools, but VSS is incredibly weak. Checking out a file to be able to edit it? Single editor at a time only? What's up with that? No thanks.
Chris D on November 7, 2007 5:24 AMI'm able - a little - to avoid the "thinking everyone else's code is crap" trap because so many of the problems I see can be blamed (or praised) on the weaker toolset they were using back when. I'm using Eclipse, and it's set to warn about pretty much everything, and I like that - but when there's a warning for, say, use of a generic collection, I can realize that typed collections weren't available when the code was written. Automated refactorings weren't there, either, which makes it at least easier to understand how methods reaching into the hundreds of lines came into being (but still...!)
Carl Manaster on November 7, 2007 5:24 AMAnd now there's an objective crap, or rather, CRAP (Change Risk Analysis and Predictions) metric. See http://www.crap4j.org/ for a tool to calculate it for Java.
Dave Aronson on November 7, 2007 5:49 AMJeff,
Ahhh... This feature is currently in Team Foundation Server 2005. I use it to backhand my coders (just kidding) on a daily basis.
Nick
Nick Berardi on November 7, 2007 5:56 AMIn a perfect world, all code would be comprehensible and easy to maintain.
We don't live in a perfect world. And there is no reason to ask 'who wrote this crap', like the borg say, it's irrellevant.
Why? Because A, you, yes, YOU have to fix, modify, replace or whatever to it. B, even if you know who wrote this crap chances are very good that they are slightly less than useless to you for fixing, modifying, etc. because of the 6 month rule.
The only real reason for who wrote this crap annotation in my mind is so that some manager can throw something is someone's face so that they can deny them a well deserved raise...
Oh, by the way, how do you get and 'R' out of Written?
It should be C.W.A.P. not C.R.A.P.
In case you didn't read the article Jeff said...
"The upcoming Visual Studio 2008, or at least the Team System flavor of it, finally delivers a feature I've wanted for years"
He knows this feature exists in other IDEs and he's just happy its in VS now. So all you my IDE is better than your IDE folks, give it a rest.
"Blame" is pretty negative. There may be extenuating circumstances why someone coded something -- they are a brand new coder, poor specs, the boss told them to rush. Or, if they're using C or C++ it's the language's fault...
Steve on November 7, 2007 6:12 AMAnyone here use AccuRev?
Ben on November 7, 2007 6:15 AMIf you re-read what I said "Team Foundation Server 2005" currently has it in production since early 2005. VS 2005 is not another IDE it is the same IDE, and the feature Jeff is talking about is currently in VS 2005 since the beta of Team Foundation Server which connects with Team Suite 2005.
Nick Berardi on November 7, 2007 6:29 AMHey Now,
I've seen alot on the new VS'08 in all that I've seen I still learn a new feature of VS from Coding Horror! I didn't know that feature was available. Thx 4 the info, nice post.
Coding Horror Fan,
Catto
It's great for Visual Studio to have something like this, but I hope it's not tied to Visual Studio. Does this rely on some proprietary source control system, or is it just a front-end for standard systems? Could somebody create another front-end for the same data? Microsoft is well-known for vendor lock-in.
Too many IDEs want to assume they're the only way the project will ever be managed. Mozilla has had a similar feature on the web for a while now. I love that anybody can use it regardless of what IDE they use or whether they have any Mozilla source code on their computer at all.
example:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/chrome/src/nsChromeRegistry.hrev=1.74
Mike on November 7, 2007 12:50 AM wrote:
"Many comments sound like this: "Oh oh oh, let me just say that this has been done, like, before, you know? So, it sucks, because it's like, not new...[Are they] writing 'new' stuff themselves?... It's ridiculous people, move on."
Well Mike, if Jeff hadn't written "..finally delivers a feature I've wanted for years...", most of these comments wouldn't have said, "Gee Jeff, you coulda had it decades ago if you'd been paying attention."
taryn on November 7, 2007 7:00 AMBen, AccuRev's next version (4.6, due out next month) has a version slider on the Annotate command that will allow you to compare any prior iteration of your file, including the ability to select and group related fields together for browsing.
Additionally, AccuRev allows you to diff *any* two versions of a file instantly, regardless of who worked on them or where.
James on November 7, 2007 7:07 AMsvn blame = svn annotate = svn praise....but no one ever uses anything but blame :)
Jason on November 7, 2007 7:33 AMIf your own year old code doesn't like like crap I submit that you haven't been learning very much in the last year.
Davide on November 7, 2007 7:35 AMEverybody's always blaming me, it ain't fair. I am not the Administrator you're looking for. That code was checked in by the Administrator next to me, while he was impersonating me.
Nice to see that everyone will have to use Visual Studio 2008 as Administrator, just like Visual Studio 2005, just like Visual Studio .Net, just like Visual Studio 6.
Administrator on November 7, 2007 7:50 AMWho codes as "Administrator" on your project ? And when is your blog engine coming out ?
I usually have a clearcase version tree open at the same time i have code open. Anyone know if there is a blame like substitute for clearcase ?
CR on November 7, 2007 8:02 AMJames Justin Harrell:
So you're wondering if a feature of Visual Studio... is tied to Visual Studio?
Nefarious.
But all seriousness aside, if you meant to say "I hope it's not tied to Visual SourceSafe," then I'm right with you. It would be nice to use this feature with SVN.
Eam on November 7, 2007 8:02 AMtaryn: "Well Mike, if Jeff hadn't written "..finally delivers a feature I've wanted for years...", most of these comments wouldn't have said, "Gee Jeff, you coulda had it decades ago if you'd been paying attention."
Well, Taryn, if *you* had paid attention, Jeff said "in Visual Studio". So those other posters can't read any better than you. :-)
KenW on November 7, 2007 8:06 AMIt might be handy to tell who changed a particular line last, but that will rarely tell you who actually introduced a bug. Even if it throws an exception on line 10, the problem may be with something that happens on line 5 that fiddles with the structure, but does it without throwing an exception.
I prefer to spend my time figuring out WHY something doesn't work than running around figuring out WHO to blame for it.
Chubber on November 7, 2007 8:06 AMLike the old NBC slogan, "If you haven't seen it, it's new to you."
Vince on November 7, 2007 8:15 AMChubber:
I think you and a few others are missing the point here. The easiest way to understand a section of code is to have the original developer explain it to you. Or better yet, you should have that original developer fix their own mistakes. You're much more likely to make a bollocks of your "fix" if the code is strange to you.
This feature just facilitates the process.
...and don't tell me you've never wondered "Who wrote this crap?"
Eam on November 7, 2007 8:16 AMIf you say to a piece of code, "who wrote this @#$#@% crap", and then later found it was none other than YOU, then you've been working too long at this company and it's time to quit and join another company!
Kashif Shaikh on November 7, 2007 9:31 AMIf you say "Who wrote this crap", then also make the initiative to "change this crap". If you can't, then you have accepted to "live with this crap", and therefore the developer who "wrote this crap" and all other subsequent developers who "lived with this crap" are all equally responsible for "this crap".
:)
This would be an interesting blog post:
Supposed you were hired at a new company.
The software you would be working on is about 10 years old.
After a few weeks on the job, you found the whole software was a fucking piece of mess, and it had too much crap. It was written by a developer just out of college using every feature of a relatively new language. It was unmaintainable, hard to understand, small changes took a long time to integrate. Because it was written in the 90s, it had a really old debugger and compiler, and tools were very lack-luster. You can't use any of the new tools today.
Problem? You can't change it, because the company has thousands of customers already using the software. The founders or original 'designers' of the software are still onboard as "Chief Architects", so they won't listen to critism and "who wrote this crap" is very sensitive.
So what do you do:
a) Quit and find another job
b) Continue working with this crappy software
c) Complain, yell, and do nothing, but say the software sucks.
d) Kill yourself
Kashif Shaikh on November 7, 2007 9:46 AMI've read so many design pattern books that I can no longer write good code. My sense of code smell is greater then my skill.
On topic. One reason I like features like this is it has potential to help Junior developers. If a senior member of a team sees some "wacky code" written by a Junior, the more experienced Dev can use that as an teaching tool.
brian on November 7, 2007 10:02 AMSecret answer D) all of the above in the following order B for a cupple months C) immediatly followed by A
Arron on November 7, 2007 10:13 AMI have a small script to do this in Perforce (called p4blame :) and have imported it as a custom tool into VS2005. Team System? Who cares - we've been using Perforce for almost 10 years and it's amazing.
amitb on November 7, 2007 10:17 AMIn emacs this is ctrl-x v g
It also has neat features like highlighting changes in the last 3, 30, 90, etc days only.
http://www.emacswiki.org/cgi-bin/emacs-en/VersionControl
http://www.emacswiki.org/cgi-bin/emacs/vc.el
Brief history: VC mode was created by Eric S Raymond in 1992. So this might be a 15 year old feature for emacs :)
//unix snob off
and to be honest I only found out about this feature in the last year :)
(noticed that the emacs comment had already been made by Richie Bielak -- I'm going to pretend I still added value because I tracked it down to 1992)
engtech on November 7, 2007 10:25 AM@Mac:
"We don't live in a perfect world. And there is no reason to ask 'who wrote this crap', like the borg say, it's [irrelevant].
Why? Because A, you, yes, YOU have to fix, modify, replace or whatever to it. B, even if you know who wrote this crap chances are very good that they are slightly less than useless to you for fixing, modifying, etc. because of the 6 month rule."
Nope. I've been using an IDE with built-in SVN support (Green Hills' MULTI) for a year-ish now, and it's amazingly useful, just as Jeff says. In big software projects, it's almost never the case that "you, yes, YOU" have to fix something on your own. Your job is to figure out how to fix things without breaking *other* things that depend on it. If you see some crap code, you can't just barge in and remove it until you understand all the dependencies... and the best way to learn about the code is to talk to the programmer who wrote it originally.
"svn blame" is the way to find out who that original programmer is. GUI support for SVN just speeds up that finding-out process.
Non-usage scenario: "Hmm, this code looks wrong. I'll change it... yep, it passes all our validation tests. Commit away!"
Usage scenario 1: "Hey, Bob, it looks to me like that (i = 0) on line 6235 should be (i = 1). I ran a couple of tests and I think I'm right, but since you wrote the original code, can you take a look and tell me if you agree?"
Usage scenario 2: "Actually, never mind, Bob. I looked at the commit log from when you committed that code, and I see that you mentioned bug report #7726. Indeed, that test case breaks if I change the code. I guess I didn't understand the code as well as I should have."
Anonymous Cowherd on November 7, 2007 10:42 AMThe blame function of svn is great. Often I'll look at something and go "who wrote this crap?", look it up in svn via blame, and find out that it was me.
Sean on November 7, 2007 10:43 AMYep, this is a cool feature. However, we've had a working equivalent for years: "Who's the last contractor who worked on the project, and since left?" "X" "It's X's fault!"
As a former contract programmer, I can say with pride: that's just one of the valuable serivces we provide our client.
A. L. Flanagan on November 7, 2007 10:45 AMHell is other people's code.
Eric Meyer on November 7, 2007 11:36 AMI don't even "blame" anymore, I just assume it's me ;)
In the Java world IntelliJ IDEA has this for quite a while.
As a feature it is only useful when you want to see who screwed up (and help him, which is good) or you want to blame somebody (which I consider to be harmful for the entire team).
If I had anything to say about what feature of an IDE should be improved, I'd go for conflict resolution.
I've smelt my own shit, and let me tell you, like my code, sometimes it's stunk to high heaven.
Jeff, note IntelliJ also has annotate integration too (at least in version 7, don't know for the previous one) and Eclipse probably has had that for a long time (although I'm not sure it's integrated in the code edition window).
Also, SVN has 3 aliases for blame: praise, annotate and ann. And Mercurial uses `ann` or `annotate`.
Note that the svn blame command also has an alias: praise. I prefer blame, naturally. Praise is for hippies.
I use ann because it's 2 characters shorter than blame.
I've seen that the biggest culprit is usually 'guest' or 'administrator', or even worse, 'test', since control over user logins has never been that strong.
Really? In SVN, unless your admin is a dunce (or the corps is so badly organized that e.g. everyone uses the same login) logins are pretty much mandatory, so I've rarely seen that problem happen.
Masklinn on November 7, 2007 12:24 PMAs a feature it is only useful when you want to see who screwed up (and help him, which is good) or you want to blame somebody
I disagree. I've used it to see when a change was performed by whom because I had to reimplement it elsewhere, this allowed me to check the files related to the change and ask the person who'd initially done it when I needed help.
If I had anything to say about what feature of an IDE should be improved, I'd go for conflict resolution.
That's a task for the VCS itself, the IDE shouldn't be used as a clutch for the VCS' failings.
Masklinn on November 7, 2007 12:26 PMoops, crutch, not clutch
Masklinn on November 7, 2007 12:26 PMboring, eclipse has this feature for years ..
MS and .NET can't keep up with the time, as always
It's a really cool and useful feature, I've used it before in Trac (or was is WebSVN?). Great to see it in Visual Studio.
Mike Weller on November 7, 2007 12:33 PMThat's a task for the VCS itself, the IDE shouldn't be used as a clutch for the VCS' failings.
I partially disagree, as the VCS can only resolve conflicts to the point where coder intervention is required. If the time comes and you have to resolve conflicts manually and the IDE just shows you ".rxxx" and ".mine" blocks you can loose precious time.
Bogdan Costea on November 7, 2007 12:38 PMMany comments sound like this: "Oh oh oh, let me just say that this has been done, like, before, you know? So, it sucks, because it's like, not new... ish, see? Basically, Microsoft sucks, always like, late... with stuff. It might be really cool, but since it's sooo 1999 I must point out that, in fact, it was done, like before, ya know."
I'd like to know if people that write such comments are writing 'new' stuff themselves? If not, do they constantly write themselves e-mail complaining their work is not original? And do they only buy a Ford car, because "they were the first to do it?" It's ridiculous people, move on.
Mike on November 7, 2007 12:50 PMIf you need complete full traceabilty from requirement to implementation, you will have to end up using a complete task driven paradigm. Coming from there, I like this approach by making use of ClearCase plus ClearQuest. More than everything it gives you traceability from all angles of interest, either project leader, system integrator, configuration manager, programmer and alike.
Marcel Z. on November 8, 2007 1:10 AMAdd netbeans to the list of IDEs which have already had this for ages.
Another case of MS playing catchup, marketed as innovation.
GUI support for SVN just speeds up that finding-out process.
That's right. Why pay the ALT+TAB tax if you don't have to? It's the integration-- inline display, right next to the code you're editing, invokable with a shortcut key -- that is so key here.
But blaming is not as good as making things right in the first place.
Yes, but which is more *fun*? I think you know the answer to that.
Jeff Atwood on November 8, 2007 3:05 AMDoes it come with an automated punishment Mechanism?
Baha on November 8, 2007 3:28 AMHarry: "Add netbeans to the list of IDEs which have already had this for ages.
Another case of MS playing catchup, marketed as innovation."
Add Harry to the list of lusers who should quit bashing MS for no reason, unless he does it on his usual appearances at /.
It isn't just other developers who can identify who wrote the crappy code. Managers can get reports to see who's-doing-what, too.
I just wrote an article for CIO about Team System's reporting features (http://www.cio.com/article/152300); the original title was "Getting the Manager off the Developers' Backs" but I guess my editor wanted to make the title more googlefriendly. Yeah. That must be it.
Anyhow, what's sort of cool (or scary, depending on one's programming ability) is how granular the manager can be in examining the results. To quote from my own article (it's terribly fun...):
But there's plenty of information that isn't part of the base reporting system. If you want to know "what's the remaining work, by person?" or "I want a list of active tasks with bugs reported" or "who introduced the most code churn?" these questions aren't answered by the out-of-the-box reports. However, the data is still available, if you're willing to massage it in Excel. [Instructions included.]
Incidentally, "code churn" is a fairly rough feature. Siddharth Bhatia clarified that yes, that includes comments. So if you want to increase code churn you can add more documentation. Whether that's a good or bad thing is, ahem, left as an exercise to the reader.
Esther Schindler
senior online editor, CIO.com
One thing I hate is where Visual Studio 2008 and the articles generated from it claim that it has a "unique reporting feature" for CIOs and Managers and let them better predict software problems.
Bull shit. Visual Studio is not going to be any different than the 100s of other tools out there.
Any SCM tool/Bug-reporting software these days lets you generate many reports on any number of projects.
I've seen fairly complex reporting features, such as Bug Close/Open rate, Fix rate, Rate of P1 and P2 bugs being filed, show-stoppers, etc.
Kashif Shaikh on November 8, 2007 9:41 AMIn defense of tools it is always desirable to find out as much as you can from whoever wrote the code in order to better understand how to modify it, however, with that said it is usually the case that they either:
a) are no longer with the organization;
b) they can't spare the time;
c) do not remember how or why they did what they did;
d) are of the belief that any 'good' coder should be able to figure it out so they won't help you;
e) are ashamed of it and don't want to discuss it;
f) want to see you fail and get fired (don't laugh, we all have perceived and real enemies in any organization);
g) are generous, humble and willing to do whatever it takes to help you out;
h) best case, they wrote it in the last month or two and can remember exactly how it works;
i) will try to help you with what they can according to their schedule.
In reality you can expect at least some help from most people as long as they aren't suffering from the 6 month rule however, chaos theory clearly indicates that rules a thru f can crop at any time and in any situation.
But like I was saying, any help is better than no help at all and any tool that allows me to get the help is a welcome addition to the tool suite.
ANKH provides this feature for Subversion from inside Visual Studio.
I used and administered Visual Source Safe 2005 for more than a year before switching our development team to Subversion, TortoiseSVN and Ankh. What a difference! I'll never go back. These Open Source tools are so much better, and who can complain with the price?
http://subversion.tigris.org/
http://ankhsvn.tigris.org/
http://tortoisesvn.tigris.org/
@Aaron G, who @Foxyshadis: "That's precisely the type of thing you should be writing comments for!"
One of the good things about integrated SVN support is that you no longer *need* to write all your comments inline, cluttering up the source, turning five-line hacks into fifty-line essays on why the hacks were at one point necessary. Sure, I agree that inline comments are useful and important in many cases, but once your organization starts using version control, you acquire the ability to write *out-of-line* comments!
Every line of code is automatically associated with a history of commit messages, all the way back to the beginning of time. Comments rot over time, getting out of sync with the evolving code --- but commit logs are associated with specific versions of the code, and thus never rot.
If a particular line looks hackish, don't guess at what it does, or try to decipher a nearby comment that might not even be accurate anymore; just right-click in the IDE, pull up the last edit on that line, and read exactly what the original author was thinking!
Anonymous Cowherd on November 8, 2007 10:50 AM@ Rob Janssen
Hehe, my bad. Didn't quite imagine M$ being that userfriendly =)
L. A. Karlsen on November 8, 2007 12:33 PMI'd just like to point out that the "Emacs had this 15 years ago" or "I've got this on my command line" debate is missing the point rather.
This was a feature of the Cray development environment from at least the 1970's if not before - the information was right there on your screen as you edited the source.
The big question is not why MS only have it now, but why everyone, open source or otherwise, hasn't had it since 1980.
Toby on November 9, 2007 2:35 AMJudge not least you be judged.
John A. Davis on November 9, 2007 4:39 AMThe problem with 'blame' is some programmers will go out of their way to avoid "owning" some code. In my last job, developers would avoid re-indenting code since the change would be then be associated with them. So we ended up with code that looked like this for instance:
for (x=0; x y; x++) {
if (x z) {
do_new_func(x, z);
} else {
do_func(x, z);
}
}
where the "if (x z) { do_new_func(x, z); }" is the new code that was added. They don't want to indent the "do_func(x, z);" since then they would become the owner of "that piece of crap". But, do this a few times and after a few iterations, the code become completely unreadable and it doesn't matter who to blame.
Howard Hong on November 9, 2007 8:04 AMI like this feature as well. Sounds great.
David Mackey on November 9, 2007 8:22 AMIn a perfect world we could just tell it what to do...
"I'm ordering you to help me go get my mom..." Terminator 2
Mac on November 9, 2007 8:35 AMHoward, you bring up a good point. If I go in and re-indent all the code then check it in, I become the "owner" of that code as the last change to it. But did I really change anything?
Compare tools really ought to compare at the token/semantic level, not at the dumb text file level.
Jeff Atwood on November 9, 2007 11:23 AMLOLOLOL
I mean CVS has the Annotate feature since two decades...
Come on you can't be so intellectual dishonest to see this as a new 'rocking' feature.
Stop praise M$ products just because you're a bit ignorant about open source and 'real community' toolkits.
Cheers!
Emanem on November 9, 2007 12:01 PMThis feature already exists for VSTS 2005. You just need to download and install TFS Power Tools and you'll be able to annotate all of the code in the file in question.
Kevin Castle on November 10, 2007 4:28 AMAs I've suspected - it was Sally.
tctctctc.
Jeff wrote:
Compare tools really ought to compare at the token/semantic level,
not at the dumb text file level.
Both would be good to have, maybe even in a side-by-side view. The former obviously is more useful for track semantic (i.e. "real") changes to code, but I can think of a few situations where the latter would also be nice to have---for instance, identifying who is writing code that doesn't conform to the local standard for indentation style (and who is having to waste time going back and fixing it). At one place I worked, two programmers (OK, one of them was me) spent a lot of time arguing over BSD vs. One True Brace style for C code, and occasionally reformatted each other's code when especially offended. Also, text-based compare might be the only way to determine when a comment has been changed, since comment text would probably not be treated as semantically significant.
Alex Chamberlain on November 12, 2007 12:11 PMOops.
s/BSD/Allman
Should've checked http://en.wikipedia.org/wiki/Indent_style first.
Alex Chamberlain on November 12, 2007 12:14 PMpointing fingers... this is what is this tools is used in a team. :)
davidecr on November 13, 2007 2:37 AMPFFFFFFFFFT TortoiseSVN has that and probably has had it for a long time. Visual Studio 2008 JUST got it??
Nicolas on November 17, 2007 11:59 AMI actually had couple of times when blame said the one who wrote this crap was me :D a very good tool when you want to go to the guy who did it and ask him if there was some reason for that or was he just lazy/drunk when he wrote it :)
Marius on August 18, 2008 5:47 AMIt is kind of nifty, it's clear in your code sample that 'Administrator' wrote the crap that returns a UrlEncoded string from a method named 'RemoveIllegalCharacters'. :P
Oh, and *bump*
Mufaka on January 12, 2009 4:28 AMThere is the application (I am too lazy to be looking for it) that you can run on Subversion and it creates a moving stars like avi movie with moving stars as files. clustering stars/files on a rule that files commited more often at once are closer to each other. with tags of names of persons commiting and showing commit dates can give a nice overview of a process of development and space like located information on people working on it.
maybe would be worth modifying the idea for this
For some really good spelunking of subversion repositories, should check out FishEye by atlassian.
http://www.atlassian.com/software/fisheye/features/annotation.jsp
We use it at work in conjunction with Jira.
Jon Gilkison on February 6, 2010 10:14 PMCode Reposited by Another Programmer?
Simon Wright on February 6, 2010 10:14 PMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |
