|
I have no opinion on FxCop because I don't use it and the only time I looked at using it, I couldn't run fast enough away from it.
|
|
|
|
|
Lucky you.
Unfortunately this decision is not up to me. I only have to live with it 
|
|
|
|
|
To be fair, I tried FxCop many times, and once, like in 2005 perhaps? it gave me good tip on how to properly implement IDisposable!
Although, since then, it has done nothing else good!  
|
|
|
|
|
I look at FXCop maybe once a year, I don't really care for it, but it does once in a while give me a good tidbit that I'll start using, but most of it is just nit picky
|
|
|
|
|
Installed FxCop.
100s of additional warnings.
(first bunch with how using statements should be inside the namespace, and yes I know you can configure the warnings, but there is a joke here)
Uninstalled FxCop.
Me: Warnings fixed. 
|
|
|
|
|
I think it's great!!! I use it in every .NET project I have by default. It's in my default Solution-wide Directory.Build.props file, so I don't even have to think about it in any new project, it's just there already.
|
|
|
|
|
Me too, I think it's great. An advanced developer might find some of the warnings unnecessary (myself included) but you just suppress them if you know what you're doing. The real benefit is for junior devs that don't understand the implications of their code (not properly implementing IDisposable for example). I probably won't use it in older, existing projects because I'd be overrun with warnings but I always use it in new code.
|
|
|
|
|
We use it and have over 75 projects in our solution, and so far it's been, well, a non issue. (I won't say "great" since that implies too much).
I can't speak to the startup times (they have always been a bit slow for my liking) but the most important thing for us is we use a custom ruleset so it doesn't complain about dumb things like the way we prefer to format code.
For us it's been an important tool to help keep things consistent.
cheers
Chris Maunder
|
|
|
|
|
Same here I'm pissed too - i totally aggree with you Mike - And I like FXCop. Everyone that says "oh i had 100 warnings then" has written code "not good". Normally from 100 FxCop Warning only 3-4 are to ignore…
But this update mess with VS 2019 is complete crap.
|
|
|
|
|
It slowed things down to a dead crawl, and gave me over 8000 warnings. Of those, roughly 7800 were complete rubbish, yet considered so Very Very Very important (in someone's imagination) that they couldn't be turned off. Pitched it after a few hours.
|
|
|
|
|
|
Wednesday at 9:30am. We call these events "meetings".
|
|
|
|
|
Nailed it! 
|
|
|
|
|
I thought it was 10:30?
wait, did you send the invite with the correct time zone?
|
|
|
|
|
The "next"?
Lets survive the current one first... Open your eyes and look around... take a close look at the people around you... See what I mean?
|
|
|
|
|
|
Who's Lance?
Will Hunter suffice?
|
|
|
|
|
Whooosh.
That was the sound of something flying over my head.
|
|
|
|
|
I'm not ready. Give me a moment to grab my gear[^]. Now, where did I put that sword?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Look for a katana hot tin roof?
|
|
|
|
|
Swords don't jam or run out of ammo, so you could put it that way.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Sage advice. Swords can break, however. Samurai always had the wakazashi should the katana fail; of course, it also worked a bit better in enclosed spaces. In short, carry a spare.
|
|
|
|
|
It seems to me that there's a reasonable argument that the thing that creates the most bugs in software is the fear of introducing bugs into the software. The fear is not unreasonable either. If you do semi-major surgery on a large piece of code, almost guaranteed you'll introduce new bugs, and possibly even some big, hairy ones with painful consequences.
But, that fear of semi-major (up to major) surgery seems so often to push folks towards always only making incremental and/or localized improvements. And that localized approach also seems to tend to create islands or layers of disparate style and technique and tools. Newer code wants to move forward but can't pull the rest along. Doesn't mean that they are ignoring the cracks in the mortar between the parts, but they just are so loath to pull it all apart and put it back together because of the possible damage.
In the end, does that ultimately lead to worse software? I think it does. But of course companies don't sell software in the end, they sell it now and have to deal with the consequences of that. And this is one of those scenarios where there kind of isn't a middle path. The middle kind of becomes the muddle that I describe above, and there's really no moderate way to fundamentally re-tool and you just have to take the pain and get it over with.
The optimal thing would be to just start a new code base, taking all the lessons learned and building it right. But that's probably a fool's paradise. It hardly ever would happen that way. The expense and the complexity and teasing all of the intricate details that have been woven into the code and perhaps not really remembered by anyone, etc... Not being able to give up the folks who really understand the current code base, so maybe different folks work on the new one and don't really have that deep understanding of what went wrong the first time, rolling their eyes at the old school crowd and their outdated concerns. And the time scale would likely have to be way too short in order to be commercially viable, so it may end up just being a new and expensive collection of different compromises.
Or of course Version 2 Syndrome with a vengeance is a possibility, and it takes twice as long to have enough meetings to decide on further ways to explore possibilities for a deeper understanding of possible modalities for scaling leverage of something or another, than it would have to just have given a small crew of talented people a room and a lot of coffee and left them alone.
Maybe in the end, the above does happen, it's just that a different company does it. Anyhoo, I'm rambling while waiting for my coffee...
Explorans limites defectum
|
|
|
|
|
I happen to agree with you.
It shows as in, I usually just refactor things to my liking. But this refactoring tendency of mine has been known to irk people... because, you know, we don't things "that way" here
(whatever "that way" is... I think it stands for "I wouldn't have written it that way")
|
|
|
|
|
A thoughtful post. A former colleague of mine called it "verification inertia", which I think was very apt. Software would be more frequently refactored if it was easier to retest. But tests are too often lacking, or the test environment too difficult to set up.
Wholesale rewriting of code is fraught with peril. It's not often attempted, and I've seen it fail more often than succeed. Here's something I wrote about it last month: [^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
