StyleCop
-
I wanted to get the few other devs here to use StyleCop, but I can't even get them to adopt FxCop. Heck, I've had to fight numerous times to keep unit tests around. One thing that scares me away from StyleCop: I ran it locally on our codebase (some 25k lines of C#) and got back more style violations than the compiler output window could handle. :)
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Feelings-Based Morality of the Secular World The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Judah Himango wrote:
scares me away from StyleCop
Same with me. I guess it has to be adopted for new projects. I think adopting FxCop should be mandatory.
Proud to be a CPHog user
-
Personally I still don't understand people who fight over style. While a style different than the one you are used too might hurt you aesthetic sensibility I found it a myth than consistent style help speed up the understanding. I downloaded and read plenty of code of 3rd party code and, as far as I'm concerned the main factor for understanding a problem is: Complexity! Either: - the topic is complex and the code is convoluted and I whinge. - the topic is simple, but the damn programer made a mess out of it, with 38 interface, 42 utility method which, put together, add 2 numbers. And I winge. - the topic is simple or complex but the programer manage to make it simple (few classes and method) and I admire. here the main fact is the number of method/class/if
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
Super Lloyd wrote:
I found it a myth than consistent style help speed up the understanding.
Completely untrue, in my opinion. Having a consistent style is incredibly important to improving the readability of the code by other team members, which, in turn, increases the quality of the code. The more readable and understandable the code, the easier it is to find bugs and fix them as you don't have to spend a lot of time trying to puzzle out the structure.
Super Lloyd wrote:
the main factor for understanding a problem is: Complexity!
Understanding a problem and being able to troubleshoot the code on screen are two different things. I have run in to numerous occasions where the problem was completely obvious from the behavior exhibited but required a non-trivial fix because the code was written in such a way as to unreadable (and no, it wasn't because the design was overly complicated with a lot of classes, interfaces, etc.).
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
-
http://blogs.msdn.com/sourceanalysis/[^]:
The new rules shipping with StyleCop 4.3 include: ... · Require parenthesis in arithmetic and comparison expressions for added clarity ...
Bogus!
----
You're right. These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.
Even stranger rule: "Don't use regions as it makes code difficult to read". I don't use #region a lot, but why were they added in the first place?
Proud to be a CPHog user
-
enforcing style? sounds like you guys have too much free time. :)
Chris Losinger wrote:
sounds like you guys have too much free time.
Yes that time can be killed by putting a new developer on ensuring that all files match stylecop rules:)
Proud to be a CPHog user
-
I am pretty religious about making sure that my code builds without any warnings when run via Code Analysis (FxCop). BTW Code Analysis is extremely useful and I personally have learned many things I was doing wrong by running CA. Now I am trying to take a step further and use StyleCop[^]. While Code Analysis rules were not as resistive and they made sense most of the times, I am facing a great deal of resistance from myself to require conformation to StyleCop rules. The advantages are obvious it provides automatic way of checking (hence it is possible to enforce easily) styles. Also, it can serve as the authoritative word if there is any disagreement in the team. I see lot of value in every member in a team using the same style. The code is easier to maintain period. Have you used StyleCop? Enforced it in your team? Any benefits?
Proud to be a CPHog user
You have pretty much listed the reasons for using it. I think the StyleCop rules should be reviewed just like FxCop to determine which ones are actually important. I use it internally for a lot of projects but haven't taken the step of introducing it at work.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
-
Judah Himango wrote:
scares me away from StyleCop
Same with me. I guess it has to be adopted for new projects. I think adopting FxCop should be mandatory.
Proud to be a CPHog user
Rama Krishna Vavilala wrote:
I think adopting FxCop should be mandatory.
Me too, but I've been unable to force the devs to adopt it. No one wants to spend time writing unit tests for their code, let alone running an external tool and fixing FxCop violations. How do you enforce it, Rama?
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Feelings-Based Morality of the Secular World The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
Chris Losinger wrote:
sounds like you guys have too much free time.
Yes that time can be killed by putting a new developer on ensuring that all files match stylecop rules:)
Proud to be a CPHog user
Rama Krishna Vavilala wrote:
putting a new developer
:omg: And he would screw up the existing logic bringing in more bugs.
Vasudevan Deepak Kumar Personal Homepage
Tech Gossips
All the world's a stage, And all the men and women merely players. They have their exits and their entrances; And one man in his time plays many parts... --William Shakespeare -
I wanted to get the few other devs here to use StyleCop, but I can't even get them to adopt FxCop. Heck, I've had to fight numerous times to keep unit tests around. One thing that scares me away from StyleCop: I ran it locally on our codebase (some 25k lines of C#) and got back more style violations than the compiler output window could handle. :)
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Feelings-Based Morality of the Secular World The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Judah Himango wrote:
I can't even get them to adopt FxCop
Do you have automated builds? Make it part of the builds.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
-
Rama Krishna Vavilala wrote:
I think adopting FxCop should be mandatory.
Me too, but I've been unable to force the devs to adopt it. No one wants to spend time writing unit tests for their code, let alone running an external tool and fixing FxCop violations. How do you enforce it, Rama?
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Feelings-Based Morality of the Secular World The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
VS 2008 has a build option: "Require Code Analysis". I have that enabled in all the projects (well almost except Web Site projects).
Proud to be a CPHog user
-
Judah Himango wrote:
I can't even get them to adopt FxCop
Do you have automated builds? Make it part of the builds.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
We use CruiseControl for the continuous integration server builds. I tried making FxCop part of the build by having CruiseControl.NET run pre-created .fxcop files for each project. I ran into problems with this: if you do a "ignore this violation" inside FxCop, then later change that code such that your ignored violation no longer applies, running FxCop from the command line will fail. (recalling this from memory 2 years ago or so) Ever see a problem like that?
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Feelings-Based Morality of the Secular World The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
VS 2008 has a build option: "Require Code Analysis". I have that enabled in all the projects (well almost except Web Site projects).
Proud to be a CPHog user
That sounds like a great option. We were using VS2005 Pro edition and it didn't have that option. (We're actually upgrading today to VSTS 2008, wish us luck.) Thanks for the advice, I think I'll do that.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Feelings-Based Morality of the Secular World The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
Even stranger rule: "Don't use regions as it makes code difficult to read". I don't use #region a lot, but why were they added in the first place?
Proud to be a CPHog user
Rama Krishna Vavilala wrote:
I don't use #region a lot, but why were they added in the first place?
I think this is another case of developers not caring to use a particular feature, then deciding that because they don't use it it's useless and consequently bad. Jeff Atwood whined about
#regionon his blog a while back - his argument boiled down to "I don't like them, and even if I did, I'd want my editor to figure out where they should be without explicit hints"; IMHO, that's inane - one might just as well assert that an IDE should expect all code to exist in a single file and provide adequate means of navigation based on the code structure. Personally, i don't care to put all code in regions... but i do consider them useful for tucking away the boring / obscure parts until / unless i actually need to read them.----
You're right. These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.
-
VS 2008 has a build option: "Require Code Analysis". I have that enabled in all the projects (well almost except Web Site projects).
Proud to be a CPHog user
Cool, I see it has a "treat warning as error" option for the FxCop violations. I think I'll enable that. :suss:
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Feelings-Based Morality of the Secular World The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
We use CruiseControl for the continuous integration server builds. I tried making FxCop part of the build by having CruiseControl.NET run pre-created .fxcop files for each project. I ran into problems with this: if you do a "ignore this violation" inside FxCop, then later change that code such that your ignored violation no longer applies, running FxCop from the command line will fail. (recalling this from memory 2 years ago or so) Ever see a problem like that?
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Feelings-Based Morality of the Secular World The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
No, I haven't seen a problem like that but I also don't use the ignore violation facilities inside FxCop itself. I prefer putting SuppressMessage attributes where appropriate in the code. That way it is always available and documented in the code without having to resort to looking in an external tool. As long as the project is compiled with the CODE_ANALYSIS symbol defined the attributes will be compiled in so FxCop will pick them up.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
-
No, I haven't seen a problem like that but I also don't use the ignore violation facilities inside FxCop itself. I prefer putting SuppressMessage attributes where appropriate in the code. That way it is always available and documented in the code without having to resort to looking in an external tool. As long as the project is compiled with the CODE_ANALYSIS symbol defined the attributes will be compiled in so FxCop will pick them up.
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
Good point, I'll keep that in mind. We are upgrading to VSTS 2008 today, and Rama mentioned FxCop analysis is built in. I'll try enforcing it from that angle.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Feelings-Based Morality of the Secular World The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
Rama Krishna Vavilala wrote:
I don't use #region a lot, but why were they added in the first place?
I think this is another case of developers not caring to use a particular feature, then deciding that because they don't use it it's useless and consequently bad. Jeff Atwood whined about
#regionon his blog a while back - his argument boiled down to "I don't like them, and even if I did, I'd want my editor to figure out where they should be without explicit hints"; IMHO, that's inane - one might just as well assert that an IDE should expect all code to exist in a single file and provide adequate means of navigation based on the code structure. Personally, i don't care to put all code in regions... but i do consider them useful for tucking away the boring / obscure parts until / unless i actually need to read them.----
You're right. These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.
I want to think at my IDE and it will, simply be the thought of the final product, write all the code for me including placement of regions naming conventions and even comments with a full user's manual. If you want to expect great things from the IDE let's get some brain power going.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
-
I want to think at my IDE and it will, simply be the thought of the final product, write all the code for me including placement of regions naming conventions and even comments with a full user's manual. If you want to expect great things from the IDE let's get some brain power going.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
El Corazon wrote:
If you want to expect great things from the IDE let's get some brain power going.
I tried coding up your idea... threw together a prototype... thought at it... ...and it wrote: "PLZ SEND TEH CODES! URGENT!!!"
----
You're right. These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.
-
That sounds like a great option. We were using VS2005 Pro edition and it didn't have that option. (We're actually upgrading today to VSTS 2008, wish us luck.) Thanks for the advice, I think I'll do that.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Feelings-Based Morality of the Secular World The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Doesn't Team Foundation Server have some sort of "require passing unit tests before you can check in" thing?
Kevin
-
Super Lloyd wrote:
I found it a myth than consistent style help speed up the understanding.
Completely untrue, in my opinion. Having a consistent style is incredibly important to improving the readability of the code by other team members, which, in turn, increases the quality of the code. The more readable and understandable the code, the easier it is to find bugs and fix them as you don't have to spend a lot of time trying to puzzle out the structure.
Super Lloyd wrote:
the main factor for understanding a problem is: Complexity!
Understanding a problem and being able to troubleshoot the code on screen are two different things. I have run in to numerous occasions where the problem was completely obvious from the behavior exhibited but required a non-trivial fix because the code was written in such a way as to unreadable (and no, it wasn't because the design was overly complicated with a lot of classes, interfaces, etc.).
Scott Dorman
Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
I meant complexity of the code, not complexity of the problem!
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
Even stranger rule: "Don't use regions as it makes code difficult to read". I don't use #region a lot, but why were they added in the first place?
Proud to be a CPHog user
I use regions, while not abusing them. 2 main uses: Group of class members (private members, constructors, properties, ...) and on top of method bodies, usually with 2 sections: parameters validation, where I throw exceptions, and assertions. When "collapsed", you can have a better view of your code without all the validation stuff in the way.