Bug number comments [closed]

Question

Why would you add

//Bug 1024

comments into a source controlled code base? Most bug tracking and source control systems are better equipted to keep track of this information. In source control, a label or comment can be used with the checkin. In a bug tracker the revision number can be added to the bug's resolution. So why comment the code? Especial since these comments relevancy is very short lived and they tend to build up littering the code base.

Answer 1

I found one of these helpful the other day in our code base.

I said "why is he calling the initialization function a second time, this late in the workflow??"

The bug comment let me go right the issue description. When I retooled the code, I was sure to include that bug in my tests and didn't reintroduce it.

Although I will say that in general I agree with you and don't insert those myself.

I would have preferred that the developer in question fixed the bug in a more meaningful way, so that I didn't have to wonder about the code in the first place.

Answer 2

Ultimately, I think it's a bad practice. It's better to include why the bug exists (foos of type Y don't have property Z). You can include a "more in BugId 12345" along with that if you want.

If you're integrating on multiple levels, a source code view in trac can link directly to the BugId.

Answer 3

Pure laziness. Sure, it takes more time in the long run, but in the short run "//Bug 1024" takes no effort whatsoever. The more code you have, the worse this is.