"There's a BUG in ...." vs User Stupidity and Blanket Statements about .NET
I"ve been doing this .NET thing since they gave out the first BETA at PDC in Orlando 2000. That's nearly FIVE years of toil and learning with the .NET platform. And I mean toil, because early on I had the good sense to completely give up on Visual Basic and go almost 100% with C#. Boy! That was a GOOD decision.
And one thing I've learned well, especially from my own mistakes and all the newsgroup and forum posts I've read and answered:
If you think you found a "BUG" in .NET, think again, because 99% of the time it's just USER STUPIDITY (and sometimes even arrogance!) that is the real problem.
There are plenty of things you can do wrong that will make it "look like" .NET is fubar, and almost without exception, it was YOU, the developer. That's not to say there aren't any bugs - of course there are. But most developers never even run into them.
It's very easy, for example, to write a stored procedure that attempts to access a table by the wrong name. This will compile just fine. At runtime, you are going to get errors that "look like" there's something wrong with the SQLDataAdapter's Update method. Nope! .NET is simply reporting the news of your stupidity, and unless you learn how to read the road signs it gives you, it may take you a long time to fix it, since you are already off "reporting a bug" -- instead of writing quality code!
Unit tests are extremely helpful in preventing errors and insuring the integrity of your codebase as projects evolve and become more complex.
But I wonder what percentage of .NET developers know how to use NUnit? Or who have read a book on unit testing or refactoring? I bet, less than 5 percent.
Think about it.
Another thing developers should be vigilant about is the temptation to accept "blanket statements" about some issue from Self-Proclaimed Guru-Types, many of whom are simply parroting something they've heard or read from some other SPGT online. A case in point is the blanket statement (which was recently made on a public newsgroup) "You should always use StringBuilder for string concatenation because ... blah, blah"
Wrong! Fact is, StringBuilder is NOT always faster or more efficient for string concatenation. I've seen several tests with charts showing that somewhere between 5 and 7 concatenations, StringBuilder is LESS EFFICIENT than "+=". Here is a link to one..
Furthermore, Jon Conwell did an excellent blog piece that shows from his tests that the String.Concat function outperforms the StringBuilder by 2.3 times! Sure there are provisos such as pre-initialization and other considerations. However, the point is, don't accept everything you read as "The Gospel". Test, and verify.
I leave you with this little gem from Tesla. When you plug your PC into the AC outlet in the wall, please thank this guy, as he invented it:
"The scientists of today think deeply instead of clearly. One must be sane to think clearly, but one can think deeply and be quite insane." -- Nikola Tesla
And one thing I've learned well, especially from my own mistakes and all the newsgroup and forum posts I've read and answered:
If you think you found a "BUG" in .NET, think again, because 99% of the time it's just USER STUPIDITY (and sometimes even arrogance!) that is the real problem.
There are plenty of things you can do wrong that will make it "look like" .NET is fubar, and almost without exception, it was YOU, the developer. That's not to say there aren't any bugs - of course there are. But most developers never even run into them.
It's very easy, for example, to write a stored procedure that attempts to access a table by the wrong name. This will compile just fine. At runtime, you are going to get errors that "look like" there's something wrong with the SQLDataAdapter's Update method. Nope! .NET is simply reporting the news of your stupidity, and unless you learn how to read the road signs it gives you, it may take you a long time to fix it, since you are already off "reporting a bug" -- instead of writing quality code!
Unit tests are extremely helpful in preventing errors and insuring the integrity of your codebase as projects evolve and become more complex.
But I wonder what percentage of .NET developers know how to use NUnit? Or who have read a book on unit testing or refactoring? I bet, less than 5 percent.
Think about it.
Blanket Statements About .NET
Another thing developers should be vigilant about is the temptation to accept "blanket statements" about some issue from Self-Proclaimed Guru-Types, many of whom are simply parroting something they've heard or read from some other SPGT online. A case in point is the blanket statement (which was recently made on a public newsgroup) "You should always use StringBuilder for string concatenation because ... blah, blah"
Wrong! Fact is, StringBuilder is NOT always faster or more efficient for string concatenation. I've seen several tests with charts showing that somewhere between 5 and 7 concatenations, StringBuilder is LESS EFFICIENT than "+=". Here is a link to one..
Furthermore, Jon Conwell did an excellent blog piece that shows from his tests that the String.Concat function outperforms the StringBuilder by 2.3 times! Sure there are provisos such as pre-initialization and other considerations. However, the point is, don't accept everything you read as "The Gospel". Test, and verify.
I leave you with this little gem from Tesla. When you plug your PC into the AC outlet in the wall, please thank this guy, as he invented it:
"The scientists of today think deeply instead of clearly. One must be sane to think clearly, but one can think deeply and be quite insane." -- Nikola Tesla
Peter, I agree 100% with this unblog. In my 3+ years using .Net, I've encountered 1 bug (regarding windows form inheritance, kb 822690 fixed it). A little research does indeed solve almost all .Net perceived problems. Keep up the "unblogs", I enjoy reading them, and I have learned a lot from this site. And I agree 100% with eggheadcafe's alter ego, Dr. Dotnetsky, what a blast.
ReplyDeleteWell!
ReplyDeleteI don't know about Dr. Dotnetsky, he's kind of a ne'er-do-well, but thanks for the nice comment!
A comment about the stringbuilder. I have seen a number of bench marks test that state the &= is faster than sb.Append from 5 to 7 concatenations. But in all cases the stringbuilder was created using this code:
ReplyDeletestringbuilder sb = New Stringbuilder()
or
Dim sb As New StringBuilder()
The above code creates a buffer of length 16. If you concatenate a string of say 50 characters, &= and sb.Append go through a similar process with the stringbuilder having more baggage. When the capacity of the sb is exceeded it doubles in size. After 5 to 7 doublings, the SB's capacity is sufficiently large. I wonder how creating the sb with this code would effect the bench marks:
stringbuilder sb = New StringBuilder(2000)
I did mention in the post that there were provisos about preinitialization, which is what you are illustrating.
ReplyDeleteMy point: Doing a bench mark and not using one of the elements of the bench mark as intended is worthless. In the link you provided, the number of characters was known in the test.
ReplyDeleteOK then. Why don't you do the test(s) yourself and publish the results, instead of criticizing others' work?
ReplyDeleteMy personal favourite is people who POST IN CAPITALS to the newsgroup that they've found a BUG in the String class. Hey, all you tens of thousands of C# programmers out there! I found a but in the most-often-used class in the entire hierarchy! A bug that nobody else has noticed!
ReplyDeleteI never know whether to pity these types, or abuse them.
They should probably learn to observe Bruce Wood's First Rule of Programming, "A mediocre standard is better than no standard at all".
ReplyDeleteCheers, Bruce.
Hi Peter,
ReplyDelete"However, the point is, don't accept everything you read as "The Gospel". Test, and verify."
Wow, what should i say, i completely agree with that comment. i have learnt this hardway. I was just trying to generate XPaths and i thought i should use the StringBuilder rather than String. But to my surprise this is what is found.As far as the pre-intialization is concerned, i guess that's a tricky issue and may not suit for all the cases.
I agree with you that you are stupid to not be able to differentiate your bug with product bugs and toil.
ReplyDelete