Fabulous Adventures In Coding
Eric Lippert is a principal developer on the C# compiler team. Learn more about Eric.
No kidding, I was just walking down a hallway in my building when I overhead the following quite loud conversational fragment through an open doorway:
Angry woman's voice: "Why are you in the ladies room?! You are the third man to... oh no."
Like Hobbes, it's the moment of dawning comprehension that I live for - the exact moment when she realized that she, not everyone else, was in the wrong room was readily apparent. (One wonders what the first two gentlemen did, since clearly they did not successfully disabuse the lady of her error.) Since the building across the courtyard from mine has a mirror-imaged layout, this is a very easy mistake to make if you are visiting from the other building.
I contrast that moment of dawning comprehension with Dr. Crusher's similar moment in that memorable 1990 episode of Star Trek: The Next Generation when she realizes that she's not crazy, it's the entire universe that is wrong. When faced with an absurd and unexpected situation - the gradual disappearance of first the crew and then the entire universe - she at least considers that she's the crazy one.
Unlike most people, I encounter compiler and library bugs all day long in my job, though mostly ones that I caused in the first place. (Sorry!) But even still, when I am writing "normal" code (rather than test cases designed to break the compiler or regress previous bugs), I try to ensure that my attitude upon encountering an unexpected situation is that I'm the crazy one. Usually it's my code that is wrong, or my misunderstanding the output, rather than a compiler or library bug.
As the authors of "The Pragmatic Programmer" point out in their third chapter, "select() isn't broken" - if you are writing perfectly normal code then odds are good you are not the first person to discover what should be an obvious problem in a well-tested product. If you think you've found a bug in the math library, maybe you have. Or maybe you've actually passed radians to a method that takes degrees, or forgotten to take floating point rounding error into account, or some other such thing. The more obvious the problem, the more likely it is that you're the crazy one. If the code doesn't compile and you think it should, it could be a bug in the compiler. But read the error message carefully; it is probably telling you what is wrong with the code.
If you think you've found a C# compiler bug, please, by all means bring it to our attention; post it on Connect, or have the community take a gander at it via StackOverflow or one of the Microsoft forums, and if you want, send me a link to the problem. (Please don't use the "contact" link to send me source code directly; the hostile-email sterilization code that filters that text is very aggressive about stripping out things that look potentially harmful. It makes code almost illegible.) There certainly are bugs in the compiler and the more we get good information on, the better. Including a small-but-complete program that reproduces the problem and the version number of the compiler you're using is a big help. But first, do stop and take a good hard look at the code and think about whether it is more likely to be a problem with the code or a problem with the compiler. Don't be one of those people who sends me angry, profane emails about a problem that you caused yourself; that's just embarrassing.
I appreciate how you appear to welcome reports of bugs in the compiler.
I would appreciate it more if these bug reports were actually welcome. So far all of them, (http://connect.microsoft.com/VisualStudio/feedback/details/594344/) fatal bugs that silently generate crashing programs, have been marked as won’t fix or otherwise been considered unimportant or unworthy of any attention.
It makes us normal people wonder what the point would be in reporting anything (which is no small amount of effort, creating a minimalist test-case and writing up the report). And it makes Microsoft appear hypocritical if one part keeps asking for bugreports and the other keeps rejecting them.
First off, we do very much appreciate bug reports, so thank you for them.
Second, we do go through and triage all the bug reports we get from Connect. We have many, many thousands of bugs and other issues that we track and not all of them can get a long, personalized reply. They all get attention, but that is not always apparent to the reporter, I know.
Third, it looks like you and Alex are having a reasonable discussion regarding the particular bug you linked to; this is evidence that the system working. It's not always clear to us what is an obscure and unlikely bug, and what real developers run into in real code. We prioritize the latter much more highly. Your explanation of how you came across this helps a lot.
Fourth, I've gotten the feedback I just got from you -- that Connect feels like a black hole into which issues and suggestions are being poured, to no effect whatsoever -- from a considerable number of developer customers over the past couple years. The problem isn't technical; this is a case of the design of the tool not matching the social or emotional expectations of the people using it.
This shortcoming is particularly vexing because (1) the dissatisfaction is irritating a very valuable set of customers: those like you who take time out of their busy days to help us improve our products, and (2) because that impression is totally false. We get great value out of having that stream of issues and suggestions, and it really does improve the product.
The community PMs are trying to figure out how to deal with the shortcomings of Connect in a way that we still get value out of the site. It is a slow process and a hard social-software-design problem to solve. Like Alex said, if you have suggestions for ways to make it better, try posting them on Connect! (The irony is palpable, I know.)