StyleCop
-
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.