Share via

Informational observations

  • Article

There are some messages that the C# compiler could give that really wouldn't fall into the warning or error camp.  These would fall into the category of more informational, like "hey did you know that..." and would refer to issues that you could choose to address or not with no ill affects.  A warning would be something like:

public class Class {

    private int property;

    public int Property {

        get {

            return Property;

        }

    }

}

"Hey! Returning the containing property could potentially lead to an infinite recursion at runtime".

or:

public class Class {

    int value;

    public Class(int value) {

        value = value;

    }

}

"Hey! Assigning a value into itself has no affect."

These are warnings on perfectly legal code but in most cases it's probably not what you wanted to do and usually indicates an error.  So while the message might be spam, it seems a reasonable tradeoff to give it to you.

An informational message is more like:

using System.Collections;
public class Class {}

"The 'using System.Collections;' state was unncessary and can be removed".

I see this sort of message as different than before because it's not really telling you of a potential problem in your code.  (Unless you expected that System.Collections was going to be used and now you're shocked that it wasn't).   It's also not really a risky thing to tell the user.  If you remove the "using" and then attempt to use a type from that namespace (like IList) we'll then give you the smart tag immediately to add it in, so it's not going to be really annoying to be adding/removing namespaces all the time.

Would these kind of messages be appreciated?  If so, would there be others that you'd find useful?  Tiny little notes that aren't necessary but would help you out with commong coding scenarios, etc.

Comments

  • Anonymous
    August 12, 2004
    I was thinking of the same thing today. It would be nice to have Visual Studio underline all the unused 'using' directives similar to the underlining of unused variables. This leads to me to a question, too. Does adding unneeded 'using' directives hurt performance at all?
  • Anonymous
    August 12, 2004
    The comment has been removed
  • Anonymous
    August 12, 2004
    Hi Cyrus,

    Great suggestion!!

    Yes, a static analysis feature built into the compiler or built into Visual Studio would definitely be appreciated. Now, of course tools such as FxCop can handle a lot of those situations, so maybe it would be easier to just integrate them with VS.NET as add-ins...

    What you're suggesting is very similar to Lint utilities for C and C++. There's a whole list of such tools at http://www.testingfaqs.org/t-static.html, but not a lot is available for .Net. DevPartner Studio from Compuware does some static analysis, as does VIL (the freeware utility at http://www.1bot.com).

    And as to the cost, obviously it should be a feature that you can turn on or off, just like the XML documentation generation etc.

    Many thanks,

    Roy
  • Anonymous
    August 12, 2004
    Such messages should be emitted and should be warnings. They're warning you that your code contains redundant elements. This is typically an indicator that you've forgotten something or improperly refactored something.
  • Anonymous
    August 12, 2004
    How about warning levels, like C++? If some of the warnings could be switched off then I would like more of the stuff currently logged in FXCop to be generated by the complier.
  • Anonymous
    August 12, 2004
    Tobias: Why would you want the FxCop stuff to be generated by the compiler if FxCop can do the checking for you?

    And you would definitely be able to turn these messages off :)
  • Anonymous
    August 12, 2004
    Dr.Pizza: That's one way to look at it. It would certainly be fine to classify these informational tidbits as low warnings.
  • Anonymous
    August 12, 2004
    Roy: The cost is not returned by being able to turn this feature off or on. The cost was already incurred by taking away resources from our current set of work to be able to do this work. Each of those other features will then have not had much time put into them as before, and turning this off won't bring that back.
  • Anonymous
    August 12, 2004
    The comment has been removed
  • Anonymous
    August 12, 2004
    I am game. I have been bitten by the property one already.
  • Anonymous
    August 12, 2004
    I was thinking it'd be great for FxCop integration with the IDE so that I could have the FxCop rules run during compilation and the warnings would appear in the compiler output and Task list.

    But I'm using VS.NET 2003 and realized you can pretty much get that with VS.NET 2005 by adding FxCop as a compiler step since your project file is an MSBuild script. Though I don't know if that will put FxCop warnings into the output window or Task list.
  • Anonymous
    August 12, 2004
    Yeah, these messages are useful, but I agree that these should be FXCop rules. You'd get the biggest return by integrating FXCop with the IDE as stated above. Then, not only do we get all of the static analysis currently done by FXCop, but we also get any rules that we want to write as well. Adding a rule doesn't impact the IDE code base. And we don't have to wait for the next version of VS to add more static analysis messages. win-win-win. (If it's possible to add that type of integration, that is)
  • Anonymous
    August 13, 2004
    The comment has been removed
  • Anonymous
    August 13, 2004
    Yes.

    Static analysis is always welcome. The first question I ask anyone who rights in C++ is "Do you use warning level 4? Why not? Is that reason really valid?" The answers, of course, are "No. Too many messages. Well..."

    I'm glad to see that Whidbey will bring static analysis tools to a first-class status. Prefix, prefast, FxCop, ... all of these are useful to ensure a certain code quality. And it look like Whidbey will be written to allow for custom static analysis tools, like those that many companies use internally.

    Yes, more warnings makes for better code.

    -Ted
  • Anonymous
    August 13, 2004
    The comment has been removed
  • Anonymous
    August 13, 2004
    Yes! Whether or not this feature gets put in the compiler, IDE, or FxCop, this feature definitely belongs in my workflow. It's nice to have someone looking over my shoulder looking for brain hiccups. And it would help eliminate some of the drivel that gets checked in by hurried team members.
  • Anonymous
    August 13, 2004
    Unused "usings" could be treated just like unused variables and generate a message, but I think in both cases the feedback comes too late. I like the way ReSharper handles it much better -- the offending code is highlited in real-time. I also second the request for an "organize usings" feature or at least for a way to define how usings should be organized so that the IDE can put them in my preferred order when it auto-adds them as part of the new refactoring feature.
  • Anonymous
    August 13, 2004
    The comment has been removed
  • Anonymous
    August 13, 2004
    Machael: I agree, having the option to highlight in real time is fantastic and is a sorely missed feature in the current VS offering.
  • Anonymous
    August 14, 2004
    Check out the C# Refactory add-in from http://www.xtreme-simplicity.net/. It has a 'tidy imports' feature that can be run at the class, project, or solution level. Very cool. Oh, and it also has almost every known refactoring feature.

    Warning - we use the 1.20 version, not the 2.0 version, which blew up when we installed it on a couple of boxes.

    Not affiliated, just a huge fan of the product. Worth the c-note
  • Anonymous
    August 15, 2004
    The comment has been removed
  • Anonymous
    August 15, 2004
    Darren: I agree with you :-)

    I don't have VS in front of me, but if I'm not mistaken you should be able to turn these warnings into errors. Something like the /we flag for C++

    If we don't have that, then we definitely should add it. For our own code base we have "treat all warnings as errors" turned on because we're fairly certain that if we ever get one of those warnings warnings chances are it will eventually turn into a bug later on. There are some warnings that are annoying, but usually reworking the code in those cases ends up with code that's actually cleaner and more maintainable.
  • Anonymous
    August 16, 2004
    ReSharper (http://www.jetbrains.com/resharper/index.html) already does pretty much of the stuff mentioned above (live errors/warnings highlighting including unused usings, removing unused usings, refactorings, etc).
  • Anonymous
    August 16, 2004
    Valentin: Thanks for the information!
  • Anonymous
    August 17, 2004
    Basically, YES YES YES! Do this. Code purists would love it, and to be honest, anything that helps me reduce the size of my code is a good thing. Of course, I understand the arguments about what it would cost to do it, but that is a decision for you guys to make. I can only say that the customer definitely would want it, and it would be beneficial. The more information you can give us about our code, the better.
  • Anonymous
    May 29, 2009
    PingBack from http://paidsurveyshub.info/story.php?title=cyrus-blather-informational-observations