New Article Published

Comments

• Jon Skeet on on 10.02.2008 at 1:27 AM

  

  Nice article. As it happens, I have a similar one about debugging - but I think the two are very complementary. Mine approaches things from a different point of view - although they have aspects in common (resting and asking other people in particular - and yes, Stack Overflow is indeed wonderful).

  It's at http://www.yoda.arachsys.com/csharp/debugging.html if you're interested in a different take on the same topic.

• schipps on on 10.02.2008 at 1:40 AM

  

  Jon, I agree they are very complementary. I like how you followed up with suggesting more testing after a bug is fixed. I have to admit I'm guilty of skimping on that one. :)

• Jon Skeet on on 10.02.2008 at 4:02 AM

  

  Oh I'm guilty of not following through on many of the things I genuinely believe to be best practice :)

  I meant to say, btw - an answer in *4 seconds* on Stack Overflow? 4 minutes I can understand, but how could anyone even load the page, read the question, type a single word and hit post within 4 seconds?

• Wes P on on 10.02.2008 at 7:48 AM

  

  I find myself forgetting about step 6, but when I remember to step back for a bit, I'm usually amazed at the progress I'm able to make afterward.

  Thanks for the article!

• James Curran on on 10.02.2008 at 10:24 AM

  

  >> 4 seconds on StackOverflow

  actually, what I think some people are doing is just immediately posting a message with just a sentence or less, then going back an editing it. So, after the editing, there are now five mostly similar answers posted (all written at the same time by different people), but that guy's post is on top, so he's the one people up arrow.

• Jon Skeet on on 10.02.2008 at 11:06 AM

  

  Yes, but even to type a single sentence (after loading the question) in 4 seconds is very impressive.

• James Curran on on 10.02.2008 at 12:52 PM

  

  Hmmm... My gravatar is wrong. I wonder if I type my email wrong. It's definitely right on this message....

• erik on on 10.02.2008 at 1:11 PM

  

  Look into using System.Diagnostics.Debug & System.Diagnostics.Trace more often! And writing DebugVisualizers, they take some time to build but save soo much time when problems occur.

  I could probaly almost write a book about them, but I don't understand why those are so overlooked, so many people don't know or use them. And they have been in .NET almost forever.

  Just catch bugs early, instead of too late (when it becomes an adventure). It's not that hard to build some util class to make it even more easy. And when you think deeply about the concepts they are even very compatible with using unit testing, etc. Sure it's a bit depending on if you are an unit test 'public interface to your app only' or test both public and private methods.

  It might even be a nice first step towards doing more unit testing. Since adding a few Debug.Assert's is a lot less work than writing unit tests and keeping them up to date.

  The compiler will just remove all your debugging code when you compile to production. Well at least if you don't modify the standard behavior =) You can even create your own methods and add the debugging attribute to them, which will auto remove them on compiling to production code. So it doesn't cause any speed like issues.

  And even trace is wonderfull, Trace saved my life a few times already, when looking into some problem that only occurs at the production enviorment.

  Anyway, I am just too obessed with the System.Diagnostics namespace =)

  Nice article, certainly a very learningfull article for the startup programmer to quickly learn where to look for solutions and how to solve problems.

• Guy Who Doesn't Understand a Word on on 10.03.2008 at 3:29 PM

  

  just writing to let you know I submitted comments to that site.

• Duane Roelands on on 10.07.2008 at 2:24 PM

  

  All ASP.NET developers need to know about trace.axd.

  1. In your web.config, Go to the <system.web> section and find the <trace> tag. Make sure the "enabled" attribute is set to "true".

  2. Sprinkle statements like System.Web.HttpContext.Current.Trace.Warn("Finished Processing") through your code. This will even work in DLLs that are not in App_Code.

  3. Go to your.application.root/.../trace.axd

  You will be rewarded with all of your trace messages, grouped by the page in which they occurred. This is -super- helpful when you're trying to debug something in production. LEAVE YOUR TRACE STATEMENTS IN PRODUCTION CODE. The very first time this saves your ass you will feel reborn. :)

• www.codingthewheel.com on on 10.08.2008 at 8:17 PM

  

  Interesting. Except the spot where you recommend Spolsky's .NET forum, which is obscure. And no mention of the MSDN forums, which are better for MS questions than even the great and mighty Stackoverflow, and less egotistical. But other than that, good stuff!

• www.codingthewheel.com on on 10.08.2008 at 8:21 PM

  

  Well, I see you mention Channel 9 and ASP.NET which are affiliated. But forums.msdn.microsoft.com is still the best resource in the world for MS-related programming & troubleshooting.

• schipps on on 10.09.2008 at 11:25 PM

  

  Thanks for the tips you guys (esp Duane who is "Cousin Developer"), will try it out.

• kp on on 10.15.2008 at 3:12 PM

  

  Very nice article!!

Post a comment