Partager via

What resolutions or warnings need to provide more information?

  • Article

One of things that we are doing for Orcas, is to basically do what we call a resolution scrub. This is where we print out every single possible resolution/warning and read over them to check for consistency, proper grammer and to see if they provide enough information for the user to both understand and fix the issue.

Unfortunately, we know that we are not there yet. An example of a change we are making is when we analyze the following:

public

 class IoWriter
{
    public void writeString(string word)
{
}

    public void writeXML(string xml)
{
}
}

In Visual Studio 2005/FxCop 1.35, the above type would fire the following four warnings with regards to the casing of name and name of its members (see the Framework Design Guidelines for more information):

    1) Correct the casing of member name 'writeString'.
2) Correct the casing of member name 'writeXML'.
3) Correct the capitalization of member name 'IoWriter.WriteXML(String):Void'.
4) Correct the capitalization of 'Io' in type name 'IoWriter'.

As you can see, for what seem to be similar checks, there are three different ways to tell the user of the problem. On top of that, even though 2) and 3) are actually raised for two different issues (one for the casing of 'write' and one for the casing of 'XML'), to the user, both seem to be finding the same problem. All four also fail to mention what the casing of the member and type names should be.

For Orcas, we will be changing the above to the following:

    1) Correct the casing of 'write' in member name 'IoWriter.writeString(String):Void' by changing it to 'Write'.
2) Correct the casing of 'write' in member name 'IoWriter.writeXML(String):Void' by changing it to 'Write'.
3) Correct the casing of 'XML' in member name 'IoWriter.writeXML(String):Void' by changing it to 'Xml'.
4) Correct the casing of 'Io' in type name 'IoWriter' by changing it to 'IO'.

At least now they all have the same wording and all of them now tell the user how to actually fix the warning.

What do you think? Is this enough? Or would you like to see more information in the warning with regards to why, for example, 'XML' and 'Io' in particular are cased incorrectly?

Apart from above, what other warnings have you encountered that do not provide enough information? I'm particularly interested in warnings that do not tell the user; 1) why the problem was raised and/or 2) how to fix the problem.

Comments

  • Anonymous
    February 03, 2007
    Great work! I like this kind of fixing things up... My opinion is that the more information the better. So to give us the hint, why it should be IO, would help. What also would help, that with a click of a mouse button, I could "disable" certain rules. At the moment I have to search for them... Keep going ;-) Cheers Harry

  • Anonymous
    February 03, 2007
    Our team has a large set of .net project and we didn't start using FxCop from the beginning. Have you ever thought of adding the funtionality to auto-fix these types of errors?  Although some errors I wouldn't want FxCop to try to fix, casing errors seem like the type of repetative monotonous task that could benefit from automation.  Even if was something like "find/replace" without a "replace all" button so that someone had to verify before it made the fix.

  • Anonymous
    February 03, 2007
    Our team has a large set of .net project and we didn't start using FxCop from the beginning. Have you ever thought of adding the funtionality to auto-fix these types of errors?  Although some errors I wouldn't want FxCop to try to fix, casing errors seem like the type of repetative monotonous task that could benefit from automation.  Even if was something like "find/replace" without a "replace all" button so that someone had to verify before it made the fix.

  • Anonymous
    February 03, 2007
    I agree with Bob D. Especially for the usually trivial, repetitive fixes, the ability to automatically fix would be great. Eclipse can automatically fix several things like missing imports and such, and I don't see Visual Studio do this kinds of usually trivial repetitive fixes.

  • Anonymous
    February 03, 2007
    Harry: The right-click, disable rule is something that we wanted to do for Orcas, unfortunately, we did not have enough time. Look out for it in future versions. Bob, Brant: I personally would prefer naming and casing issues to be raised before you build. Imagine raising these issues as you type (you could also see us hooking onto the refactoring tools to help making sure that any consumers get updated with the new name), sort of like the Office spell checker.

  • Anonymous
    February 04, 2007
    In Orcase, will analysis be built into the IDE?  (I remember someone saying this quite some time ago).  If so, it'd be great if the warning/error was 'squiggled' at the appropriate point in the code. The user could then click and have the IDE do the changes! Cheers, Steve.

  • Anonymous
    February 05, 2007
    The CA1006:DoNotNestGenericTypesInMemberSignatures rule in Microsoft.Design definitely needs help! There isn't even an example of how to fix the problem in the documentation! You might consider checking your current set of rules to make sure that all the violations have appropriate solutions. Thanks! Bryant

  • Anonymous
    February 05, 2007
    Byrant: Thanks for the feedback. We're are definately improving the docs to include better examples and explanations, I'll make sure to put DoNotNestGenericTypesInMemberSignatures on the radar.

  • Anonymous
    February 07, 2007
    The comment has been removed