|
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."
|
|
|
|
|
CDP1802 wrote: Like William Shatner or Captain Kirk? Both at March 22
AWESOME!
Happy B-Day[^], Pete! (nvsfw)
|
|
|
|
|
I will issue a pre-emptive thank you for everyone's best wishes. A 5 will be automatically allocated. You can count that as my thanks.
|
|
|
|
|
Happy Birthday Pete ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
Isn't it boring after all that years?
Nevertheless - happy birthday!
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
May the Force be with you!
Happy Birthday and keep up trainig those who seek the Force
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
Happy Birthday
Pete O'Hanlon wrote: pre-emptive
For some reason (beyond my comprehension) I read that as 'pre-empire', made absolutely no sense but...
Tom
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Jig | [Dance]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/jig.gif)
