StyleCop
-
Ahh, Dogma Driven Development (DDD) and your personal Big brother to enforce evry single rule. Why does that thing not write the code by itself as long as it knows everything better?
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada."Couldn't agree more. I wish that the tool provided automatic re-formatting where possible. Better yet, I'd prefer that the lenses in my eyes would automatically reformat code the way that I find it most helpful.
-
Hmm, Super Lloyd I think you nailed it on the head in that you don’t want to be bothered with style issues so StyleCop may be seen as just an impediment. Nothing wrong with that. StyleCop certainly takes a lot of getting used to and if the benefits of its use won’t be realized, well, just like anything else, probably best not to go down that path.
We started using StyleCop 5 years ago in one project and moved to use it in all of our in-development C# projects, ~70. Prior to its usage, styles varied wildly and conflicted making for a difficult to read, modify and navigate code base. We've gone from a team of 5 developers up to 12 and now to 4.
A few notes:
- It is not that StyleCop rules are always right, it’s the fact that they are always enforced that, IMHO, is the big win. Ever have to listen to, or explain about style in a code review? Tool usage might be easier. – megaadam mentioned this as well.
- Enforcing that StyleCop warnings are errors or turn them all the way off to avoid spewing warnings that never get fixed.
- Understand that it takes quite a while to get used to the level of checking. It took me about 6 months but around then I just stopped doing things that would cause errors, same thing goes with Code Analysis.
- Some team members had to give up the idea that their code style was part of who they were or how they expressed themselves. Once they got over that, they were the biggest proponents of the tool.
- The <inheritdoc/> tag can be used when implementing overrides where the base class documentation is sufficient to avoid duplication.
- The <include file='....'/> tag can be used for documentation that would otherwise have been copied and pasted.
- A CustomDictionary.xml can be used to inform StyleCop of naming overrides.
- The argument that things should be placed next other things which are most related works great until it doesn’t. For example, two methods or properties that use the same field – where should the field be located?
- I don’t know what you are referring to when talking about #regions begin required around using statements. #region’s and StyleCop don’t get along together well and most of our code base does not use #region’s. The only requirement I know of is the ordering and placement of namespace using statements; they must be within the enclosing namespace and grouped and order by name.
Interesting comment yippiecoder thanks! :) The 2 documentation tag tips are interesting!
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
-
For new job, I am setting up a pilot project right now. They suggested I use StyleCop. They suggested I remove all the rule I don't like, but at least it's there to check a few things worth checking... Playing with it right now.. I see plenty of useless or annoying rule... What are your thoughs and/or experience with that? rule about space, tabs, bracket after a if.. feeling like removing them... rule about space around comma! :omg: rule requiring a space after '//' :wtf: some rules about commenting... well it's wishful but it's cumbersome.. particularly as I have verbatim copy paste code I now have to comment as well... a little unsure about that... rule about prefixing with "this." gonna flat remove those... rule requiring a #region block around using statement! :zzz: rule requiring to order method by protection level (public first, private last): absolutely set against that! I like grouping method by use, if 2 method work together, they must be next to each other (preferably) :mad: I think that, basically, I just don't like StyleCop! Bummer! I was trying to be more political this year! :((
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
I've never even really noticed StyleCop before this, but I get the impression here that you can't change the rules? If you can't configure the rules so suite your standards, then it's a worthless piece of dung not even worth mentioning.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
-
For new job, I am setting up a pilot project right now. They suggested I use StyleCop. They suggested I remove all the rule I don't like, but at least it's there to check a few things worth checking... Playing with it right now.. I see plenty of useless or annoying rule... What are your thoughs and/or experience with that? rule about space, tabs, bracket after a if.. feeling like removing them... rule about space around comma! :omg: rule requiring a space after '//' :wtf: some rules about commenting... well it's wishful but it's cumbersome.. particularly as I have verbatim copy paste code I now have to comment as well... a little unsure about that... rule about prefixing with "this." gonna flat remove those... rule requiring a #region block around using statement! :zzz: rule requiring to order method by protection level (public first, private last): absolutely set against that! I like grouping method by use, if 2 method work together, they must be next to each other (preferably) :mad: I think that, basically, I just don't like StyleCop! Bummer! I was trying to be more political this year! :((
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
You've had quite a few replies - some love StyleCop and some really don't like the need to code in a specific way. I actually understand both viewpoints. I once worked with a coder in the early 90's who was he was recommended as a guru by another company. One of the many personal coding styles he insisted on was that indentation was for wimps. He took every opportunity to rail at the request that he should indent (and many other equally silly things) - he was actually pleased that it made it harder to read, since then only the good developers would be able to understand the code. Good coders have their own styles. They quite often have strong opinions on style. They probably vary from the other good coders in the team. They also probably refactor each other's code to conform to their style. I think that good coders who work in teams need to play nicely with each other and part of this is to agree on a style and stick to that. It helps code readability and predictability for the team (once they are used to the style). This in turn reduces bugs and the cost of maintenance. Good coders write excellent code. Great coders leave a legacy that the rest of the team can keep in top condition. If this is going to be a large, mission critical project which can impact lives (Financial, emergency services etc) and have many team members thrown at the project, then maybe having a clean, well structured, easy to read and maintain codebase is important. Maybe also lower bugs and cost to maintain is also important. Maybe have a chat to your team about this. Or perhaps try it for a few months and see what you think after this time. Kent Cooooooooooooode
-
Me was thinking , if I really don't care about style, I could keep them after all! So me think, perhaps I do care about style hey? At any rate I will certainly NOT keep the rule where things (method property, event) should be order by access level and type! I rather keep related things together, like the backing filed of a property next to it! And I am not too sure about documentation everywhere. It's nice to have, but what if you copy some code project library source code in my libraries... might have to spend day documenting... plus, worse than that, people might comment wrong! since.. it's annoying...
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
If you're allowed to turn off rules you don't agree with, then this gives you the opportunity to set the coding standard for this pilot - which sounds like a fair amount of trust in your decisions :) The method/property/event ordered by access type sounds like something with little payoff vs grouping similar methods ec together. If you don't like it, and you're given the green light to work out which rules should be enforced, then just turn it off. Maybe if you are not sure about a rule, leave it on for a while and see if the resulting code ends up cleaner or easier for your teammates to quickly get up to speed with your code. Having to document every public method also sounds like overkill unless you are creating a library for third parties to use. Kent
-
For new job, I am setting up a pilot project right now. They suggested I use StyleCop. They suggested I remove all the rule I don't like, but at least it's there to check a few things worth checking... Playing with it right now.. I see plenty of useless or annoying rule... What are your thoughs and/or experience with that? rule about space, tabs, bracket after a if.. feeling like removing them... rule about space around comma! :omg: rule requiring a space after '//' :wtf: some rules about commenting... well it's wishful but it's cumbersome.. particularly as I have verbatim copy paste code I now have to comment as well... a little unsure about that... rule about prefixing with "this." gonna flat remove those... rule requiring a #region block around using statement! :zzz: rule requiring to order method by protection level (public first, private last): absolutely set against that! I like grouping method by use, if 2 method work together, they must be next to each other (preferably) :mad: I think that, basically, I just don't like StyleCop! Bummer! I was trying to be more political this year! :((
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
FXCop actually looks better than stylecop, and is more flexible. It does style as well as picking up potential issues. Until I read this thread, I thought that FXCop was depreciated and that StyleCop was the new FXCop - and I was wrong. I used FXCop a long time ago and it ROCKED. Why don't you suggest FXCop to the team.
-
You've had quite a few replies - some love StyleCop and some really don't like the need to code in a specific way. I actually understand both viewpoints. I once worked with a coder in the early 90's who was he was recommended as a guru by another company. One of the many personal coding styles he insisted on was that indentation was for wimps. He took every opportunity to rail at the request that he should indent (and many other equally silly things) - he was actually pleased that it made it harder to read, since then only the good developers would be able to understand the code. Good coders have their own styles. They quite often have strong opinions on style. They probably vary from the other good coders in the team. They also probably refactor each other's code to conform to their style. I think that good coders who work in teams need to play nicely with each other and part of this is to agree on a style and stick to that. It helps code readability and predictability for the team (once they are used to the style). This in turn reduces bugs and the cost of maintenance. Good coders write excellent code. Great coders leave a legacy that the rest of the team can keep in top condition. If this is going to be a large, mission critical project which can impact lives (Financial, emergency services etc) and have many team members thrown at the project, then maybe having a clean, well structured, easy to read and maintain codebase is important. Maybe also lower bugs and cost to maintain is also important. Maybe have a chat to your team about this. Or perhaps try it for a few months and see what you think after this time. Kent Cooooooooooooode
Kent Bolton wrote:
Maybe have a chat to your team about this
Ok Kent, I might chat with my team about that! :laugh:
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
-
I do not. We perform exactly the same task (in C++) manually in code reviews. And we are about to introduce a tool that fixes the formatting automagically at every git push. It hurts my eyes to read inconsistent code like this.
if( check_func(a,b, c ,d)) {
process(long_Name ); }else if ( verifyFUNC( zzz))
{
discard( shrtNme);
}I really large software projects (+1.000.000 lines, +50 people), a bit of consistency is fairly nice. So the point is not so much rule A vs. rule B as simply consistency.
Life is too shor
Kudos... Humans can adapt to various standards quick enough (IMHO). So, having basic standards, and using tools to help enforce them is good. I have some bad habits from my Pascal/Delphi days (If/Then vs. if/then), that get fixed up for me. But it SUCKS when you are trying to get up to speed on a bunch of code, and EVERYONE used a different indentation/BRACE approach (as in your example). I prefer the BRACES on their own line. But I can adapt to any consistent code base. An inconsistent one (like your post above) drives me batty! Kirk Out!
-
For new job, I am setting up a pilot project right now. They suggested I use StyleCop. They suggested I remove all the rule I don't like, but at least it's there to check a few things worth checking... Playing with it right now.. I see plenty of useless or annoying rule... What are your thoughs and/or experience with that? rule about space, tabs, bracket after a if.. feeling like removing them... rule about space around comma! :omg: rule requiring a space after '//' :wtf: some rules about commenting... well it's wishful but it's cumbersome.. particularly as I have verbatim copy paste code I now have to comment as well... a little unsure about that... rule about prefixing with "this." gonna flat remove those... rule requiring a #region block around using statement! :zzz: rule requiring to order method by protection level (public first, private last): absolutely set against that! I like grouping method by use, if 2 method work together, they must be next to each other (preferably) :mad: I think that, basically, I just don't like StyleCop! Bummer! I was trying to be more political this year! :((
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
SuperLloyd, I'm disappointed to read of your decision against defenestration of StyleCop and all of its ilk. I am perhaps the least respected individual in my group because of my failure to (for instance) enclose single-statement blocks in brackets, in an IF statement. And ya know what ? I don't care. Worse, if they are very short, I will place two or even (very infrequently)three statements ON A SINGLE LINE (enclosed in brackets, of course) immediately following the predicate. ON THE SAME LINE ! Oh! The Horror! Worse still, I rarely use 'this' in accessing a class variable. And the worst sin of all, I completely ignore the convention of placing a property's 'Get' & 'Set' on separate lines and separate blocks (except where a 'get' or 'set' is extraordinarily complex). That vertical-format property rule MUST have been set forth by a computer printer paper salesman. Now, I DO comment the heck out of my code ... indeed, apparently to a fault. People have complained about my excessive commenting. I don't care. My feeling is that I'm CERTAIN to forget what I was doing in as little as two or three weeks. Where the code gets complex, I document the heck out of it so that six months down the road when I'm back in the code, I can come back up to speed (relatively) quickly. So, I do suffer the slings and arrows of the style zealots, but that's a small price to pay. I'm sorry to hear that you've surrendered to the zealots in The Good Fight.
-
For new job, I am setting up a pilot project right now. They suggested I use StyleCop. They suggested I remove all the rule I don't like, but at least it's there to check a few things worth checking... Playing with it right now.. I see plenty of useless or annoying rule... What are your thoughs and/or experience with that? rule about space, tabs, bracket after a if.. feeling like removing them... rule about space around comma! :omg: rule requiring a space after '//' :wtf: some rules about commenting... well it's wishful but it's cumbersome.. particularly as I have verbatim copy paste code I now have to comment as well... a little unsure about that... rule about prefixing with "this." gonna flat remove those... rule requiring a #region block around using statement! :zzz: rule requiring to order method by protection level (public first, private last): absolutely set against that! I like grouping method by use, if 2 method work together, they must be next to each other (preferably) :mad: I think that, basically, I just don't like StyleCop! Bummer! I was trying to be more political this year! :((
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
Except for the rule about #region blocks around using statements, I'm a big fan of StyleCop. I was first introduced to it when I started at my current job. Sure, adding StyleCop to an old project sucks: *Build - Succeeded* *Add StyleCop* *Build - 678 Errors* But you can't beat the uniformity. It's all about readability and consistency to me. I'm a bit of a perfectionist, so when I have to read someone's code that has mixed indention, inconsistent bracketing, poor naming convention, and crammed code (yeah, I'm talking to the guys who take the challenge to put as much code on as few lines as possible... this isn't code golf!) I get a bit annoyed. My 2 cents.
-
SuperLloyd, I'm disappointed to read of your decision against defenestration of StyleCop and all of its ilk. I am perhaps the least respected individual in my group because of my failure to (for instance) enclose single-statement blocks in brackets, in an IF statement. And ya know what ? I don't care. Worse, if they are very short, I will place two or even (very infrequently)three statements ON A SINGLE LINE (enclosed in brackets, of course) immediately following the predicate. ON THE SAME LINE ! Oh! The Horror! Worse still, I rarely use 'this' in accessing a class variable. And the worst sin of all, I completely ignore the convention of placing a property's 'Get' & 'Set' on separate lines and separate blocks (except where a 'get' or 'set' is extraordinarily complex). That vertical-format property rule MUST have been set forth by a computer printer paper salesman. Now, I DO comment the heck out of my code ... indeed, apparently to a fault. People have complained about my excessive commenting. I don't care. My feeling is that I'm CERTAIN to forget what I was doing in as little as two or three weeks. Where the code gets complex, I document the heck out of it so that six months down the road when I'm back in the code, I can come back up to speed (relatively) quickly. So, I do suffer the slings and arrows of the style zealots, but that's a small price to pay. I'm sorry to hear that you've surrendered to the zealots in The Good Fight.
Hear ye, Hear ye! One hasn't given up the good fight! Well, partly I want to be political, partly I am tired of COMPLETELY USELESS fighting! If people feel their happiness depends on no space after comma, no tabs, always curly braces on next line even for single statement if, well.. let's do it and move on! :laugh: ;P But I feel you man! :-D
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
-
I've never even really noticed StyleCop before this, but I get the impression here that you can't change the rules? If you can't configure the rules so suite your standards, then it's a worthless piece of dung not even worth mentioning.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
You can turn rules on/off, apparently you can even write your own! But the majority of the rules are just really stupid (the creator must have been an OCD intern!), to give you an idea there is a single rule for "element must have comments" and it applies to public/protected/private/internal field/property/method/class all at once! :~ :(( I would have like mandatory public method comment but not worth it...
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
-
You can turn rules on/off, apparently you can even write your own! But the majority of the rules are just really stupid (the creator must have been an OCD intern!), to give you an idea there is a single rule for "element must have comments" and it applies to public/protected/private/internal field/property/method/class all at once! :~ :(( I would have like mandatory public method comment but not worth it...
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
Super Lloyd wrote:
I would have like mandatory public method comment but not worth it...
Get an intern to write that rule for you. :laugh: Yes, an intern or someone very junior get told to a) Read the MS recommended coding conventions, b) write n many rules to check them all, and c) feel free to try and impress your boss by making up rules like mandatory comments for fields. I much prefer using something like ReSharper[1] to keep my own code pretty, and in a company, a quick code review should easily reveal really ugly zits on someone else's code. They should also be using something to keep in pretty, even if they have to resort to old fashioned hand formatting.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
-
You've had quite a few replies - some love StyleCop and some really don't like the need to code in a specific way. I actually understand both viewpoints. I once worked with a coder in the early 90's who was he was recommended as a guru by another company. One of the many personal coding styles he insisted on was that indentation was for wimps. He took every opportunity to rail at the request that he should indent (and many other equally silly things) - he was actually pleased that it made it harder to read, since then only the good developers would be able to understand the code. Good coders have their own styles. They quite often have strong opinions on style. They probably vary from the other good coders in the team. They also probably refactor each other's code to conform to their style. I think that good coders who work in teams need to play nicely with each other and part of this is to agree on a style and stick to that. It helps code readability and predictability for the team (once they are used to the style). This in turn reduces bugs and the cost of maintenance. Good coders write excellent code. Great coders leave a legacy that the rest of the team can keep in top condition. If this is going to be a large, mission critical project which can impact lives (Financial, emergency services etc) and have many team members thrown at the project, then maybe having a clean, well structured, easy to read and maintain codebase is important. Maybe also lower bugs and cost to maintain is also important. Maybe have a chat to your team about this. Or perhaps try it for a few months and see what you think after this time. Kent Cooooooooooooode
Good coders do have their own styles, but if that style makes code harder for others to read, that coder should only be working in isolation.
No object is so beautiful that, under certain conditions, it will not look ugly. - Oscar Wilde
-
Me was thinking , if I really don't care about style, I could keep them after all! So me think, perhaps I do care about style hey? At any rate I will certainly NOT keep the rule where things (method property, event) should be order by access level and type! I rather keep related things together, like the backing filed of a property next to it! And I am not too sure about documentation everywhere. It's nice to have, but what if you copy some code project library source code in my libraries... might have to spend day documenting... plus, worse than that, people might comment wrong! since.. it's annoying...
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
If you feel that strongly about a public and private method belonging together to the exclusion of another public method, that is probably a code smell that they belong in another class, together.