Hacker News new | ask | show | jobs
by Metasyntactic 3494 days ago
Hi Gacek,

> Integration of style-cop-like rules seems ok, my only worry is that all those features will make VS sluggish

They really shouldn't. We've actually spent the majority of our time in VS2017 on perf. So even with all the extra functionality, it's significant faster and more responsive across the board.

One thing that helps out here is that we don't run any of this analysis in the core VS process. As such, we are not contending for any resources that VS itself needs. i.e. a large source of hiccups in VS was due to the GC having to run right when a UI request was coming in. By moving this analysis out of proc we dramatically lighten the memory load in VS and we make it so that the GC runs less often, and takes less time. This clears up the UI thread more and makes things much more responsive.

> Either you are a member of your team, and you don't write code without them, or it's some old code, that shouldn't be automatically refactored if the refactoring is the only goal.

Or, you're a team that has decided on new, more stringent, coding requirements. And now you want to find and fix up all the violations. Or you're absorbing code by a different group with different coding patterns. Or, you just missed something during a code review and you want to go fix it up :)

If teams have a style preference, then it is definitely valuable to have automated tooling checking to ensure the style is maintained. Otherwise you're shifting the burden onto the team members, which is precisely what tooling like this is supposed to alleviate.

> And that braces refactoring seems a poor example.

NOte: we've added many style options in VS2017, and we're going to continue adding more. Options include:

1. Do you want field/property/methods/events qualified with "this." or not 2. Do you prefer predefined types (like "string") or do you prefer the .net fx types (like "System.String") 3. How and when do you use "var". 4. Do you want to use => for simple properties/methods/etc. 5. Would you prefer to use the more concise typechecking constructs over the previous approaches for type-checking. 6. Do you want to use ?? or ?. when applicable

etc. etc.