What is a BUGBUG?

项目
03/29/2005

One of the internal software engineering traditions here at Microsoft is the "BUGBUG".

Bugbug's are annotations that are added to the source code when the developer writing the code isn't sure if the code they're writing is "correct", or if there's some potential issue with the code that the developer feels needs further investigation.

So when looking through source code, you sometimes find things like:

// BUGBUG: I'm sure these GUIDs are defined somewhere but I'm not sure which library contains them, so defining them here. DEFINE_GUID(IID_IFoo, 0x12345678,0x1234,0x1234,0x12,0x12,0x12,0x12,0x12,0x12,0x12,0x12);

The idea behind a BUGBUG annotation is that a BUGBUG is something that you should fix before you ship, but that won't necessarily hold shipping the product for - as in the example above, it's not the end of the world if the definition of IFoo is duplicated in this module, but it IS somewhat sloppy. Typically every component has a P1 bug in the database to remove all the BUGBUG's - either turn them into real bugs, or remove them, or ensure that unit tests exist to verify (or falsify) the bugbug.

As far as I know, the concept of a BUGBUG's was initially created by Alan Whitney, who was my first manager at Microsoft - I know he's the first person who explained their use to me. Lately they've fallen out of favor in favor of more structured constructs, but conceptually, I still like them.

Comments

Anonymous
March 29, 2005
The comment has been removed
Anonymous
March 29, 2005
The comment has been removed
Anonymous
March 29, 2005
BUGBUG: "either turn them into real bugs, or ... "

Cool practice... I was always wondering why such a smart and experienced developers working at MS has so many bugs - they add them intentionally to make less-experienced developers and customers feel happy then they will find/hit any of them ;-)
Anonymous
March 29, 2005
The comment has been removed
Anonymous
March 29, 2005
AT: Actually that's why bugbug is out of favor - people took the term out of context and said that's why Microsoft has so many bugs - they put them in the text.
Anonymous
March 29, 2005
Where i used to work we used to have //TODO comments sprinkled all over our code with similar sorts of things.

That is, until management decided that these "todo"s needed to be actually "done" and started generating reports based on the number of todo comments in our code.

Needless to say, as soon as that happened, we started simply deleting the comments whenever we checked in (to keep the numbers down) and writing our real todos as //ODOT to fool their silly reports.

I guess my point is that while formal methods for tracking issues are a good thing, you still need something more informal, if only to flag at a code review or something. Engineers are a funny lot - impose formalities on us and we'll rebel any way we can :)
Anonymous
March 29, 2005
C:WINDOWSINFmshdc.inf

(Yes it's on the C drive because I haven't repartitioned and reinstalled the OS on this one.)

From Windows 95 through 2000 there was a BUGBUG where the developer was asking what something does. My best guess is that it wasn't part of the actual problems that Windows systems have had in handling disk drives though. In Windows XP it changed into an ISSUE (but there's a new BUGBUG to make up for it). I forgot to look for it in Windows 2003. Maybe it'll be changed in Longhorn tonight ^_^
Anonymous
March 29, 2005
The comment has been removed
Anonymous
March 29, 2005
Dean - wouldn't it be better to educate the management as to the meaning and importance of these comments rather than dispensing with a useful system of tracking such issues? Just a thought...
Anonymous
March 29, 2005
!! is not the best of flags to use: how else do you convert a sort-of-Boolean into a real-Boolean value?

As BUGBUG being "quaint" - yes, but it's robust too, and that's more important. If it's in ASCII source text, you don't depend on whatever elegant source code maintenance system you are using still being around when you need to look at the code in 2025.
Anonymous
March 29, 2005
Norman, good catch - whoops :)

I just checked, it's on my version of the INF file as well (on this machine at least), and that's on XP... I've not checked W2K3...
Anonymous
March 29, 2005
Martin: Absolutely. And thinking of it as ASCII art's a fascinating idea, I wish I'd thought of it :). Given that NT's gone through at least two different source code control systems (and has taken source projects in from still others), it'd be hard to imagine something like this that could survive too long.
Anonymous
March 29, 2005
Martin: By writing
real_boolean = (sort_of_boolean != 0) ?
Anonymous
March 29, 2005
Martin :
!! is not the best of flags to use: how else do you convert a sort-of-Boolean into a real-Boolean value?

simply checking if the expression is different from its false constant ?

BOOL bFakeBool1 = ...
int iFakeBool2 = ...

bool bRealBool1 = (bFakeBool != FALSE);
bool bRealBool2 = (iFakeBool2 != 0);
Anonymous
March 29, 2005
In many open source projects I've seen the FIXME marker instead.
Anonymous
March 29, 2005
I believe the infamous "Windows 2000 shipped with 63,000 known bugs" was referring to bugbugs... gotta love the press.
Anonymous
March 30, 2005
I use FIXME and TODO when I'm adding "buggy" code, but I use BUGBUG? when I'm noting a possible bug in someone else's existing code. <:)
Anonymous
March 30, 2005
The comment has been removed
Anonymous
March 30, 2005
The comment has been removed
Anonymous
March 30, 2005
Jonathan mentioned media and their misrepresenation "Windows 2000 shipped with 63,000 known bugs".

Partially kidding, but...

How large is the bugfix list for NT5sp4 now? ;->
Anonymous
March 30, 2005
Most of the reported Windows 2000 bugs were produced by a static analysis tool run just before we shipped, but before we could fix them. We probably should have waited to move them into the bug database until after we shipped, but who was to know that these numbers would be leaked to the outside world. Many of these bugs were not bugs, so the number is certainly inflated. At least we weren't hidding bugs from ourselves. There was a push to get rid of BUGBUGs from the source, so groups just replaced them with other keywords instead of addressing the issues they were documenting. But they didn't use the same keywords across the whole source base. I found it assuming when I discovered BUGBUGs in 15 year old code I work on changed to FEATUREs by someone who at least had a certain amount of humor.
Anonymous
March 30, 2005
So know that we know what a BUGBUG is, what's a BIGBUG? ;)
Anonymous
April 01, 2005
Where I work, we used to have a macro that turned TODOs into #pragma message statements, but it fell out of favor because the compiler output got cluttered with trivial, low-priority fixmes. If an issue is so bad that it needs to be fixed before compiling, there's no point in trying to come up with a decoration for it -- just use #error so there's no way it'll compile. That's how I remind myself what I was working on when I come in on Mondays.
Anonymous
May 24, 2005
The comment has been removed
Anonymous
August 11, 2006
PingBack from http://www.livejournal.com/users/kroman139/3705.html
Anonymous
August 11, 2006
PingBack from http://www.ljseek.ru/%D0%BA-%D0%B5-bugbug-larry-osterman-s-weblog_157860.html
Anonymous
August 05, 2007
PingBack from http://fluxcapacity.net/2007/08/05/month-1-breaking-in-the-garage/

通过

What is a BUGBUG?

Comments

其他资源