|
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!
|
|
|
|
|
I really like the this. rule. I used to use Stylecop, once it got me in to good habits I do find that my code naturally comes out cleaner now.
|
|
|
|
|
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 f***ing 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.
|
|
|
|
|
Is it supposed to be used just for coding style "enforcement"? I tried StyleCop once and got really sick of it. I like Gendarme[^] from the Mono project a lot. It's more about static code analysis. Unfortunately it's not integrated into VS.
|
|
|
|
|
FxCop yes, StyleCop no.
The FxCop rules can be easily Googled, and there's a reasoning documented.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Indeed!
|
|
|
|
|
I don't really care about method ordering. I use the drop down in the IDE anyway, to find the method i need.
Also, I use ReSharper extensively (for many reasons), so finding methods is a cinch, especially in large APIs.
|
|
|
|
|
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:
1. 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.
2. Enforcing that StyleCop warnings are errors or turn them all the way off to avoid spewing warnings that never get fixed.
3. 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.
4. 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.
5. The <inheritdoc/> tag can be used when implementing overrides where the base class documentation is sufficient to avoid duplication.
6. The <include file='....'/> tag can be used for documentation that would otherwise have been copied and pasted.
7. A CustomDictionary.xml can be used to inform StyleCop of naming overrides.
8. 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?
9. 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!
|
|
|
|
|
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...
|
|
|
|
|
Super Lloyd wrote: I would have like mandatory public method comment but not worth it... Get an intern to write that rule for you.
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
|
|
|
|
|
Kent Bolton wrote: Maybe have a chat to your team about this
Ok Kent, I might chat with my team about that!
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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!
But I feel you man!
|
|
|
|
|
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.
|
|
|
|
|
|
I always associated Yoda with Methuselah, from the Bible. He was old 969+ years before his death, and wise.
|
|
|
|
|
Happy birthay from me as well.
From the astrological perspective, you should have hung on for another 11 days. Being born on march 21 or at least on one of the following days would have made you invincible
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 f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
|
|
|
|
|
CDP1802 wrote: would have made you invincible He is invincible!
Your time will come, if you let it be right.
|
|
|
|
|
He is? Like William Shatner or Captain Kirk? Both at March 22, that can't be a coincidence.
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 f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
|
|
|
|