StyleCop
-
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.
-
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
Scott Dorman wrote:
Having a consistent style is incredibly important to improving the readability ...
This kind of quite widespread attitude have translated, as far as Im concern, into endless discussion such as: - "Use tabs instead of space (or the opposite)" - "Always put a bracket after a if/for, or do not put a bracket for a single instrcution" Not only this instruction conflict from person to person, but I personally found that, the ratio of the length of time debating the merit of each these versus the benefit is a complete waste of time...
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.
-
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 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
StyleCop type features are useful for inexperienced developers and developers that make a lot of mistakes. Once you develop a consistent rhythm you should trust your self. Part of development is an art. My rule of them is, once you learn the science move to the art but don't start the other way around. The bigger problem with mandating a style for everyone is you make a few assumptions 1) That the style is mandated is the best style possible and 2) you don't care about innovation. I would be willing to wage that for every successful software project (success measured as on-time and meets all functional points and under budget) you fill find 100 projects without mandated style for every project with. You will also notice a correlation between project failure and increased number of developers as well as the correlation between number of developers and institution of such things as style rules. I would say, anecdotal, that there would not be a correlation between project cost.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego. -
shhhhhhhh! no one is supposed to know my real name is Steven Falkin....
_________________________ 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."
-
Scott Dorman wrote:
Having a consistent style is incredibly important to improving the readability ...
This kind of quite widespread attitude have translated, as far as Im concern, into endless discussion such as: - "Use tabs instead of space (or the opposite)" - "Always put a bracket after a if/for, or do not put a bracket for a single instrcution" Not only this instruction conflict from person to person, but I personally found that, the ratio of the length of time debating the merit of each these versus the benefit is a complete waste of time...
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.
-
Scott Dorman wrote:
Having a consistent style is incredibly important to improving the readability ...
This kind of quite widespread attitude have translated, as far as Im concern, into endless discussion such as: - "Use tabs instead of space (or the opposite)" - "Always put a bracket after a if/for, or do not put a bracket for a single instrcution" Not only this instruction conflict from person to person, but I personally found that, the ratio of the length of time debating the merit of each these versus the benefit is a complete waste of time...
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:
This kind of quite widespread attitude have translated, as far as Im concern, into endless discussion
This is absolutely a case of picking your battles. Consistency in style can, and often does, go way beyond these types of "holy war" debates. There are actually a lot of psychological factors that come in to play with a good code style/standard that effectively create a self-fulfilling prophecy when it comes to code quality. If you want to dictate matters like tabs vs. spaces, then you have to be prepared to back up the decision with valid justification and be willing to enforce what could be an unpopular decision. Of course, there are ways to lessen the impact of such decisions, if one really must dictate them.
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
-
That's precisely why it shouldn't be debate, it should be chosen and enforced. (Obviously by someone in a position to do this).
my thought on the topic is that it should be left to the developer to do as he feels comfortable with... because these has no other impact than frustrating the developer...
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.
-
Doesn't Team Foundation Server have some sort of "require passing unit tests before you can check in" thing?
Kevin
I'm not sure. We're using SVN rather than the built-in VS source control.
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
-
I'm not sure. We're using SVN rather than the built-in VS source control.
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
Only if you use Team Foundation server, that the check in policies can be ensured. BTW VS 2005 also has Code Analysis.
Proud to be a CPHog user
-
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
A colleague of mine uses regions to separate, e.g. different cases in a switch statement. It drives me mad.
il
-
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.
Reshaper makes regions nice. In file structure view, you can drag and drop methods etc. between existing and new regions, and to me this really makes regions work. Once I'm done coding, I can group vertically or horizontally related members into regions in a summary view.
il
-
:rose: Just watched Saw IV last weekend. This franchise is a stayer.
il
-
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 have seen developers using region blocks within large methods heavily to logically organize the code, which is not a very good idea. At times it is also used as a replacement for traditonal comments. Since i always use VS 2005, i prefer to use regions within my methods as it neatly groups the code and it is easy to explain the code pieces to others.