StyleCop
-
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.
-
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.
Actually I think that's a good idea, which do you think is clearer: marginLeft + columnWidth * columnCount - overlay / factor + marginRight or marginLeft + (columnWidth * columnCount) - (overlay / factor) + marginRight No, I don't know what overlay is either.
-
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.
You have a good point there mate! I think they are useful as well, but are easily abused. I have seen developers using regions instead of methods.
Cheers, Dani
-
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.
We use regions to group functions in essentialy any code file. If it's business logic toward database then it gets getters inserts etc regions. If it is form or control then it gets Variables, Properties, Events, Helper Functions, Button handlers and others. And it helps a lot when you look at somebody else's code and you need to overview it quickly. You may or may not like regions, but they are here and we might as well use them. It's up to team consensus HOW they will be used.
-
We use regions to group functions in essentialy any code file. If it's business logic toward database then it gets getters inserts etc regions. If it is form or control then it gets Variables, Properties, Events, Helper Functions, Button handlers and others. And it helps a lot when you look at somebody else's code and you need to overview it quickly. You may or may not like regions, but they are here and we might as well use them. It's up to team consensus HOW they will be used.
-
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.
I recently inherited a project where every single method was wrapped in its own region. Evil!
-
Doesn't Team Foundation Server have some sort of "require passing unit tests before you can check in" thing?
Kevin
Yes
-
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
Not the Standard or Professional editions.
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
-
:rose: Just watched Saw IV last weekend. This franchise is a stayer.
il
Brady Kelly wrote:
Just watched Saw IV last weekend. This franchise is a stayer.
On Thurs, saw an ad on the back of a bus for Saw V opening Oct 23 (Australia).
T-Mac-Oz "When I'm ruler of the universe ... I'm working on it, I'm working on it. I'm just as frustrated as you are. It turns out to be a non-trivial problem." - Linus Torvalds
-
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.Ennis Ray Lynch, Jr. wrote:
- That the style is mandated is the best style possible and
Doubtful, I think the goal is consistency. Sure a new (to the team) developer will take some time to adjust to the mandated style. They may not like it & be less productive as an individual than they would be if allowed to retain their "individual" style, but on group projects, the key to success is teamwork. If every member of a team has a unique style, then when someone leaves, goes on vacation, is sick or otherwise indisposed, maintenance work on the absent member's area(s) will involve adjustment to their individual style. As a manager, that's not something I want my team wasting time on when there's a critical bug out in the field! (And invariably, these things surface when the original developer is absent!). Better each new developer take a little longer to ramp up so that everyone is on the same page.
- you don't care about innovation.
I don't see how a mandated style could stifle innovation, any more than the structure required by the development language would. If part or all of the team is working on new stuff that isn't covered by the style guide, just expand the guide! Unless you believe there is a correlation between stylistic freedom & creativity? <rant> It is beyond my comprehension why so many people equate stylistic freedom with creativity! Shakespeare wrote some of the most beautiful poetry ever within the rigid constraints of the style required for a sonnet[^], not to mention his consistent use of iambic pentameter[^] throughout his plays. If a developer has trouble expressing concepts outside their own narrow view of the way things should be done (according to them), I find it doubtful that their "creative" ideas would be all that innovative - more likely something that has been solved & solved again, just in a way they don't easily recognise. "Re-inventing the wheel" is still rife in development circles. </rant>
T-Mac-Oz "When I'm ruler of the universe ... I'm working on it, I'm working on it. I'm just as frustrated as you are. It turns out to be a non-trivial pr