FxCop experience?
-
So I though: let's make a clean version of my library and there was FxCop (1.35). But thing didn't go so well after that, it's mostly stupid! For example 2 error it report: 1. CriticalWarning, Certainty 75, for IdentifiersShouldBeSpelledCorrectly in public ReadOnlySegment(T[] a, int pos, int len) , consider providing a more meaningful name than the one-letter parameter name 'a'." 2. "Rename 'PowerText.Utils.Segment`1' to end in 'Collection'." (because: public struct Segment : IList ??) After carefull review... there are some usefull rule... but they are lost amidst stupid other one... what da ya think?
I could group error by rule, so I have a faster view of what's relevant! cool!
-
So I though: let's make a clean version of my library and there was FxCop (1.35). But thing didn't go so well after that, it's mostly stupid! For example 2 error it report: 1. CriticalWarning, Certainty 75, for IdentifiersShouldBeSpelledCorrectly in public ReadOnlySegment(T[] a, int pos, int len) , consider providing a more meaningful name than the one-letter parameter name 'a'." 2. "Rename 'PowerText.Utils.Segment`1' to end in 'Collection'." (because: public struct Segment : IList ??) After carefull review... there are some usefull rule... but they are lost amidst stupid other one... what da ya think?
There are fairly good detail descriptions for each rule, and you can select which to check for. On your examples:
ais a bit on the unintelligible side :)Segment ==> *Collection: I hate that. While it's good to see from the name the class behaves like a collection, "ElementCollection" is very unexpressive.
Some of us walk the memory lane, others plummet into a rabbit hole
Tree in C# || Fold With Us! || sighist -
So I though: let's make a clean version of my library and there was FxCop (1.35). But thing didn't go so well after that, it's mostly stupid! For example 2 error it report: 1. CriticalWarning, Certainty 75, for IdentifiersShouldBeSpelledCorrectly in public ReadOnlySegment(T[] a, int pos, int len) , consider providing a more meaningful name than the one-letter parameter name 'a'." 2. "Rename 'PowerText.Utils.Segment`1' to end in 'Collection'." (because: public struct Segment : IList ??) After carefull review... there are some usefull rule... but they are lost amidst stupid other one... what da ya think?
My new employer uses it and I'm quite pleased with it. It means everyone's code is a lot cleaner without code reviews (you still need those, but FxCop picks up on the mundane stuff)
"On two occasions, I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able to rightly apprehend the kind of confusion of ideas that could provoke such a question." --Charles Babbage (1791-1871) My: Website | Blog
-
There are fairly good detail descriptions for each rule, and you can select which to check for. On your examples:
ais a bit on the unintelligible side :)Segment ==> *Collection: I hate that. While it's good to see from the name the class behaves like a collection, "ElementCollection" is very unexpressive.
Some of us walk the memory lane, others plummet into a rabbit hole
Tree in C# || Fold With Us! || sighistpeterchen wrote:
a is a bit on the unintelligible side
:laugh: Well.... I would argue it's acceptable... ;P
-
So I though: let's make a clean version of my library and there was FxCop (1.35). But thing didn't go so well after that, it's mostly stupid! For example 2 error it report: 1. CriticalWarning, Certainty 75, for IdentifiersShouldBeSpelledCorrectly in public ReadOnlySegment(T[] a, int pos, int len) , consider providing a more meaningful name than the one-letter parameter name 'a'." 2. "Rename 'PowerText.Utils.Segment`1' to end in 'Collection'." (because: public struct Segment : IList ??) After carefull review... there are some usefull rule... but they are lost amidst stupid other one... what da ya think?
I will listen to a computer generated suggestion when its poetry, else :mad:**
How xacc.ide transforms text to colored words on the screen
Intel PentuimM (aka Centrino) undervolting**
-
So I though: let's make a clean version of my library and there was FxCop (1.35). But thing didn't go so well after that, it's mostly stupid! For example 2 error it report: 1. CriticalWarning, Certainty 75, for IdentifiersShouldBeSpelledCorrectly in public ReadOnlySegment(T[] a, int pos, int len) , consider providing a more meaningful name than the one-letter parameter name 'a'." 2. "Rename 'PowerText.Utils.Segment`1' to end in 'Collection'." (because: public struct Segment : IList ??) After carefull review... there are some usefull rule... but they are lost amidst stupid other one... what da ya think?
I totally agree that naming a variable 'a' is bad form. Developers have put a lot of time into setting up the rules so as to ensure you code to a certain standard. Some may not be applicable to your situation, but I've not come across any I would call "dumb". cheers, Chris Maunder
CodeProject.com : C++ MVP
-
So I though: let's make a clean version of my library and there was FxCop (1.35). But thing didn't go so well after that, it's mostly stupid! For example 2 error it report: 1. CriticalWarning, Certainty 75, for IdentifiersShouldBeSpelledCorrectly in public ReadOnlySegment(T[] a, int pos, int len) , consider providing a more meaningful name than the one-letter parameter name 'a'." 2. "Rename 'PowerText.Utils.Segment`1' to end in 'Collection'." (because: public struct Segment : IList ??) After carefull review... there are some usefull rule... but they are lost amidst stupid other one... what da ya think?
When we were a .NET shop (good riddance ;P ) I was using FxCop, and even tried to introduce it to other developers, but no one else seemed to care about it.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-
I totally agree that naming a variable 'a' is bad form. Developers have put a lot of time into setting up the rules so as to ensure you code to a certain standard. Some may not be applicable to your situation, but I've not come across any I would call "dumb". cheers, Chris Maunder
CodeProject.com : C++ MVP
I'm not one those person who don't care much about { } versus { } or variableName, versus VariableName. even though I follow and favor the convention :-) ( having worked with people who strictly enforce opposite style I learned that this has little importance... ;P ) Now having a tool which usefullness seems limited to enforce that kind of thing doesn't struck me as ... great. I was hoping for ... something special, and it turns out to be just a convention enforcer... (or so it seems) But let's give FxCop a fair trial, I will try to use it and follow its advice for a little while. I will see what I think after that...
-
When we were a .NET shop (good riddance ;P ) I was using FxCop, and even tried to introduce it to other developers, but no one else seemed to care about it.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
After a bit of testing (5 minutes) it looks to me as being little more than a "convention enforcer". I can't say I'm impress ... In fact I'm disappointed :(
-
After a bit of testing (5 minutes) it looks to me as being little more than a "convention enforcer". I can't say I'm impress ... In fact I'm disappointed :(
Super Lloyd, You have to remember FxCop's history, which started off as a exactly that; a 'convention enforcer' for the .NET Framework Guidelines. However, these days we have not only naming and spelling rules, but also security (CallGCKeepAliveWhenUsingNativeResources, ReviewSqlQueriesForSecurityVulnerabilities, etc), correctness (ProvideCorrectArgumentsToFormattingMethods, RethrowToPreserveStackDetails, etc) interop/portability (PInvokeDeclarationsShouldBePortable, PInvokeEntryPointsShouldExist, etc), design (ValidateArgumentsOfPublicMethods, ImplementIDisposableCorrectly, etc), performance (AvoidUnnecessaryStringCreation, AvoidUncalledPrivateCode, etc) and globalization (DoNotPassLiteralsAsLocalizedParameters, DoNotHardcodeLocaleSpecificStrings, etc). Within Visual Studio Team System we also have some reliability (DisposeObjectsBeforeLosingScope, DoNotLockOnObjectsWithWeakIdentity, etc) and maintainability (AvoidExcessiveComplexity, AvoidExcessiveInheritance, etc) rules. I think one mistake that new users make, is that they try to fix every issue. A lot of rules such as the collection naming one you encountered above, are only applicable if you are designing a reusable Framework, if not, turn it off. If you have any concerns about any rules, don't hesitate to head over to the FxCop Forum[^] and tell us what you think. David M. Kean VS Code Analysis Team My Blog: Managed from Down Under | Team Blog: FxCop Blog -- modified at 11:21 Sunday 11th June, 2006
-
Super Lloyd, You have to remember FxCop's history, which started off as a exactly that; a 'convention enforcer' for the .NET Framework Guidelines. However, these days we have not only naming and spelling rules, but also security (CallGCKeepAliveWhenUsingNativeResources, ReviewSqlQueriesForSecurityVulnerabilities, etc), correctness (ProvideCorrectArgumentsToFormattingMethods, RethrowToPreserveStackDetails, etc) interop/portability (PInvokeDeclarationsShouldBePortable, PInvokeEntryPointsShouldExist, etc), design (ValidateArgumentsOfPublicMethods, ImplementIDisposableCorrectly, etc), performance (AvoidUnnecessaryStringCreation, AvoidUncalledPrivateCode, etc) and globalization (DoNotPassLiteralsAsLocalizedParameters, DoNotHardcodeLocaleSpecificStrings, etc). Within Visual Studio Team System we also have some reliability (DisposeObjectsBeforeLosingScope, DoNotLockOnObjectsWithWeakIdentity, etc) and maintainability (AvoidExcessiveComplexity, AvoidExcessiveInheritance, etc) rules. I think one mistake that new users make, is that they try to fix every issue. A lot of rules such as the collection naming one you encountered above, are only applicable if you are designing a reusable Framework, if not, turn it off. If you have any concerns about any rules, don't hesitate to head over to the FxCop Forum[^] and tell us what you think. David M. Kean VS Code Analysis Team My Blog: Managed from Down Under | Team Blog: FxCop Blog -- modified at 11:21 Sunday 11th June, 2006
Yes, I saw a few interesting rules in plain black lost among numerous naming one in bold red... I guess the tool need a bit of getting used to it to really appreciate it to its real value. Thanks for the link by the way!
-
I totally agree that naming a variable 'a' is bad form. Developers have put a lot of time into setting up the rules so as to ensure you code to a certain standard. Some may not be applicable to your situation, but I've not come across any I would call "dumb". cheers, Chris Maunder
CodeProject.com : C++ MVP
Chris Maunder wrote:
I totally agree that naming a variable 'a' is bad form.
Especially when it's a publicly-visible parameter...
---- Scripts i’ve known... CPhog 1.0.0.0 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
Chris Maunder wrote:
I totally agree that naming a variable 'a' is bad form.
Especially when it's a publicly-visible parameter...
---- Scripts i’ve known... CPhog 1.0.0.0 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
In this particular case I stand by it! It serves a purpose similar to this one: public List ( IEnumerable<T> collection ) 'c' would be allright by me. would it be so developer confusing to use 'c' instead of 'collection' ? I don't think so. Doesn't cause me any trouble. But if only to please you (and potentially bad tempered developer, who knows?) I will rename 'a', uh... 'underlyingArray' or 'theArray' instead :-D
-
In this particular case I stand by it! It serves a purpose similar to this one: public List ( IEnumerable<T> collection ) 'c' would be allright by me. would it be so developer confusing to use 'c' instead of 'collection' ? I don't think so. Doesn't cause me any trouble. But if only to please you (and potentially bad tempered developer, who knows?) I will rename 'a', uh... 'underlyingArray' or 'theArray' instead :-D
The point is, it really doesn't save anything to use
cinstead ofcollection, orainstead ofarray. Why make me waste that extra half-second thinking about it, when you can make it so completely obvious with just a few extra keystrokes?---- Scripts i’ve known... CPhog 1.0.0.0 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
The point is, it really doesn't save anything to use
cinstead ofcollection, orainstead ofarray. Why make me waste that extra half-second thinking about it, when you can make it so completely obvious with just a few extra keystrokes?---- Scripts i’ve known... CPhog 1.0.0.0 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
mhh... I get your point ;)