C# Compiler warnings

I wrote the code snippet tool using Everett (VS7.1).  At one point, I struggled for a bit with a typo I had made.  Here's a simplified version of the code I had:

if (someMethodThatReturnsABool());
return;

What got me was the semicolon at the end of the first line.  When I tried it out in today's Whidbey drop, I was happy to see we're now generating a warning for that case.  This is one of many scenarios the compiler can avoid wasting the developer's time spent on frustrating little mistakes.  Another example is when a property returns itself causing an infinite loop (I don't think we've added a warning for this one yet, but it's definitely on our radar). 

In many cases though, even when the warning would be helpful in most cases, we end up not adding a warning for a scenario in order to not generate much noise.  If we went ahead and added more warnings liberally, developers could potentially start ignoring warnings or turning them off completely, which is not where we want to end up. 

With that in mind, are there any scenarios you have run across that you feel would benefit by getting a warning added to the compiler to cover them?  Feel free to send them my way if you have any.

Comments

• Anonymous
  March 23, 2004
  I wish this had actually been made illegal in the language (requiring {} instead). C# cleaned up so many little things that caused common errors in C/C++, like being able to fall through in case statements by leaving out the break.
  
• Anonymous
  March 23, 2004
  Static analysis for checked exceptions
• Anonymous
  March 23, 2004
  Generate a list of non-public methods that are never called and can be eliminated. It already warns us about non-public fields that are never used - do the same for methods.
  
  Also, is there a means (e.g. #pragma warn) to disable specific warnings? If not, there ought to be.
  
• Anonymous
  March 23, 2004
  The comment has been removed
• Anonymous
  March 23, 2004
  I suggest using curly braces for "if" statements. Two extra characters to type, but this type of bug is dodged.
• Anonymous
  March 24, 2004
  Give us plenty of warnings and the ability to turn them on and off.
  
  I'm already ignoring the warnings because the compiler is insisting on warning me when I write a class that implements an interface that contains an event but the class never fires that event.
• Anonymous
  March 24, 2004
  The comment has been removed
• Anonymous
  March 24, 2004
  Note to self, when simplifying a code scenario test it before posting. I just tried the code I mentioned in the entry and Everett also warned in this situation. So when my "simplification" wasn't correct and now I don't remember what exactly my case was. I'll try to figure it out soon though.
  
  Regardless, the question I ask still remains. Thanks!
• Anonymous
  March 24, 2004
  Here's a more esoteric warning request...given the construct...
  
  try
  {
  // statements that can throw
  }
  catch(SomeException ex)
  {
  if ( somecondition )
  {
  // handle the error
  }
  }
  
  There should be a warning that the catch clause can fall through without any action taken. In other words, the default behavior of this is to swallow and ignore the exception if none of the if conditions are satisfied.
  Constructs that would not generate a warning are those cases that either have an unconditional else clause or code following the last if clause.
  
• Anonymous
  March 25, 2004
  One thing I think we could definitely benefit from a warning for is something like this:
  
  class Dog
  {
  private string name;
  
  public Dog(string name) {
  name = name; // assigns parameter to itself, which is useless. note missing this. qualifier.
  }
  
  // rest of class
  
  }
  
  This error is fairly easy to debug, but common and obviously unintended.
• Anonymous
  March 29, 2004
  The comment has been removed
• Anonymous
  April 01, 2004
  Doug, the latest drops now warn in any case where you're assigning the value of a variable to itself. So that covers yours.
  
  Dave/Patrick, thanks, we'll consider these.
• Anonymous
  July 04, 2004
  A [Used] attribute would be nice to have, which informs the compiler that a variable which seems to have no purpose really is important. (Such as in the case of reflection, or a public Event that is never called that is needed for an interface.)