Hash tagging your code, but is it a good idea ?

The finished product, http://thecodebase.com/bang/ .

I started hash tagging my comments on the project I'm working on, doing things like

// Refactor this to use inheritance !charlie

// Rewrite this once we know for sure that we won't need to edit the workflow !frank

Then, to see what I had left to do, I would grep for them

grep -rin '!charlie' .

And when frank came on board to the project, he could grep for '!frank' to see what I needed help with.

I preferred this over creating tickets, mostly because I'm lazy, and I don't want to login to some website, fill out a bunch of fields.

But also because I think these things don't belong in a ticketing system. What I was tagging was very code specific, it wasn't a vague intermitent problem, it was concrete code related problems.

"I need help your help with this". "Fix this before release 1".

I finally got motivated to write a script that would parse these out, and because I was all javascript on this project ( node + extjs + mongo ), and I had another project I was using python on, I decided just to make it support both languages. The result is http://thecodebase.com/bang/ , a python script to parse them, and node+extjs to make them all pretty like.

I showed this to friends , and friends of friends, and here are some reasons why they thought it was a bad idea.

• I already have a ticket system, I don't want to look in two places
• Why is this better than //TODO that my IDE already highlights ?
• //TODO's and //FIXME's are just wrong and you shouldn't use them
• Charlie you're an idiot stop talking to me

For me, I didn't want full fledged tickets. And I didn't really use what we had anyway, its much easier for me to type 'bang' and get a list of things to do.

And this was born out of //TODO's. The problem I was having was that it was just a random list of things to do. If I was in the mood to work on 'refactoring', i'd have to go through and read all of them to get to the refactoring tasks. With bang I could categorize them. Sort them by priority. See if I could help !gnovy with his !ui stuff.

For some people "ticketing" systems is mostly a management tool, more tickets makes it look like your code sucks. And I have worked at companies like this, it's stupid, but it happens. But as a result they didn't really have a place other than //TODO's to report things that needed doing.

But the larger idea of commenting the source code to keep track of what to do being bad practice is still a question . On the one hand, I can see it being bad in that if you see a problem with the code ( a //FIXME ), you should fix it. Don't make a comment, fix it.

On the other hand, what if I just found a bug before leaving for mandatory meeting X. I don't want to go update the ticket, I don't have time. I comment it, and come back to after this worthless meeting. And there are other things besides FIXME's. For instance some of my code dealing with workflow was getting just way too complicated, but other things were still in flux, I didn't want to dedicate time at that moment to refactor it, but I knew it had to be done eventually, so I tagged it, completely intending to refactor it when decisions were finally made regarding the business logic.

And eventually I did refactor it. Because I had tagged it, and I got tired of it staring me in the face all the time.