The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Anything that is unrelated to elephants is irrelephant Anonymous - The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944 - Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
I just turned my message analysis on...
And in the see of 400 warning for library I am look at right now. I think I spotted 2 useful comment....
They really need to improved this feature... :/ (i.e. I can't spot the 0.5% useful comments most time)
like style | possible error | pattern recommendation
I certainly don't care about style consistency in my home project. Better yet, I like to change style over time! Ha! Take that stupid style enforcer!
Found a solution.. instead of simply ignoring code analysis.. I create a ruleset, disable everything and the cherry pick a few promising looking rules...
what I really would like to know is, how easy to make new one?
I'd like to create a warning when people to await Task object (which throw no warning in non async method by default)...
Would caught some bug in our project... :/
I checked those 3 rules
- Avoid excessive inheritance
- Avoid excessive complexity
- Avoid unmaintainable code
Now I am curious to see where it will apply ^^
The fracking ruleset doesn't work! (in Visual Studio 2019 Community)
I told it to ignore rule 2208, restarted Visual Studio, it still warns me about it...
That's it, stuff it, I can't be bothered to use it anymore... there might be 0.5% useful warning, but they are just too hard to use...
I never quite got this obscession with style anyway. The computer does not care about it at all, as long as the parser can make sense of what it has been fed. And I have also seen enough pigs with stylish lipstick, yet still most developers do their best to ignore the real problems and just make a big fuss to prevent the lipstick from getting smeared.
Sometimes I think this is some sort of modern supersticion. They invent arcane rituals with arcane rules which don't really help very much, but are fanatically persued anyway.
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.
Definitely. To me, it also explains the explosion of languages for this and that which are supposed to "make it easier." Plus, there is this movement that says, "everyone can code." Unfortunately, we can not add the adverb "well" to the end of that sentence. It would be more like, "sort of."
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
Style is important because you're writing code for developers to read, not for computers.
When style is consistent, code will look familiar at first sight and it will save any other developer, or you next year, the trouble of first deciphering the syntax before actually trying to understand what it does.
When I see code that's not properly formatted or otherwise inconsistent I immediately assume the developer is lacking in skill and/or professionality and I'm usually right.
It's really easy to keep code consistent, especially with today's tools, and it saves a lot of effort when reading it so why not just do it?