We had two great chats last Friday. Thank-you to all that attended, I had a lot of fun.
The following is a list of Code Analysis questions that were asked:
Q: JeffBe: I’m very interested in the code metrics, are these integrated into build reports though? We’d like to be able to track code metrics over time.
A: This is something that we’ve received a lot requests for. Unfortunately, for Orcas we won’t be integrating this into TeamBuild or any sort of reports. However, this is definitely something that we want to do in a future release.
Q: Where can i find more information about CyclomaticComplexity feature in Orcas ?
A: Besides what we’ve already published on our blog (http://blogs.msdn.com/fxcop/), there’s not much information around at the moment. This will change in Beta 2, we also do plan on doing more in-depth posts on the blog in the coming months.
Q: I’ll ask the audience. What would be your preference on something that we should focus on in Code Metrics? 1) TeamBuild integration 2) Extensibility (the ability to add your own metrics) 3) Policy Enforcement of Metrics (being able to prevent check-ins of code that doesn’t pass a certain threshold of maintainability. 4) More extensive metrics
Q: Extensibility, enforcement, more extensive metrics (in that order)
A: Thanks Peter. You want to plug in your own metrics? Do you think we’re missing some?
Q: metrics. Complexity is a bit subjective–that’s something that would be best suited to customization. I’d be a big proponent of something that measures degree of Law of Demeter violations…
A: Yes we’ve heard that. This is one of the reasons we really want to wait to see what customization customers really want. ie Do they simply want to tweak the numbers that make up the magic ‘Maintainability Index’, or do they want to completely replace the metric altogether.
Q: Did you have to do anything special with CodeAnalysis in Orcas to support multiple versions of the .NET Framework?
A: The great thing about Orcas is that we actually get this for free. The new MSBuild mult-targeting means that you simply select the Framework you want to build against and Code Analysis ‘just works’.
Q: Any idea if nStatic-like features will be added to code analysis?
A: While I haven’t yet played around with nStatic (I don’t believe it has been released), we are looking at doing a lot more advanced analysis in a future version of Visual Studio.
Q: Any added Code Analysis rules for C# 3.0 language extensions?
A: Unfortunately no. Similar to the introduction of the .NET 1.0, it’s still not very clear on the gotchas and mistakes that people make when writing Linq. With regards to the other features, such as Extension methods, Automatic Properties, etc what would you like to see?
Q: The Static Analysis results are published to the data warehouse, will we ever see them in the build reports? Or is there a way to customise the build reports to include them?
A: Grant, I’m not an expert on our integration with Team Build, but I’ll certainly pass this request onto them.
Q: I guess I’m out of luck on var (doesn’t make it into the assembly, per se). I know many people watching C# 3. demos are really put off by wholesale abilities of their developers to use features like extension methods.
A: It’s pretty likely that you won’t see any rules from us ‘stating’ don’t use Extension methods. 😉 However, this wouldn’t be too hard to write a simple rule to do this. We are thinking about releasing rule samples when Orcas releases, I’ll make sure this gets chucked in.
Q: to specifically answer your question “…missing some”. Not really, other than possibly new C# 3.0 stuff. Most of the rules would be very specific to either an in-house class library or the way one shop mandates coding/design.
A: As you know, a lot of the C# 3.0/VB 9 improvements are simply syntactic sugar over IL. So it actually makes it hard to write rules that target them. What I actually meant though, do you think we’re missing some metrics?
Q: David: Question for you, in addition to FxCop do you think a tool similar to StyleCop will be available in the future? Although API level code analysis is great there are certain rules we’d like to enforce on non-public code constructs.
A: As you well know, FxCop/Managed Code Analysis currently runs over an assembly and not actually the source code. To change this would be a significant change. However, in saying that, this is one of many features we may consider doing in a future release, however, if we do end up doing it, it’s likely to be more a long term feature, rather than short term. For the next couple of versions at least, you will still see binary analysis.
Q: I think the greatest potential of TFS/CodeAnalysis is in customization. Given it’s something that makes it to the assembly level, for shops to be able to define their custom rules and enforce them at check-in would be a huge plus.
A: Peter we hear ya loud and clear. This is definitely something that we want to focus on in the future. The question is, do we focus on making rules more customizable or do we focus on allow teams to write their own rules? What does everyone think?
Q: RE: customizable/rule-creation. I think rule creation would tend to be more accepted. Most of the shops I deal with accept most of the out-of-the-box rules and I can’t think of many that could be improved by customization (bar metrics…).
A: What about naming/casing guidelines? Do you see many shops wanting to customize these or are they happy following the Design Guidelines?
Q. We do having naming standards that are a subset of the Design Guideline, i.e. we’ve made some rules more restrictive so we would want to customise these.
A: Good to know. Will bring this to the product team.
Q: Is a release of FxCop planned to coincide with the RTM of Orcas? What classes of code analysis with TFS include that FxCop won’t?
A: It is likely that the next version of FxCop will be released sometime around the release of Orcas. Things that are included in Visual Studio that FxCop does not have are (but not limited to); Code Analysis Policy (the ability to enforce that code passes particular rules on check-in), Maintainability and Reliability rules, Code Metrics, out-of-the-box support for MSBuild (so warnings can be displayed in the Error List) and a few other features.
Q: Are there any updates coming to FxCop 1.35? It’s been a long time since release, and there are several bugs.
A: Although I can’t get give an exact date, we do plan on releasing an update to FxCop sometime in the next quarter. What bugs are you hitting?
Q: The fxcop bugs are generally “rule exceptions”. We have worked around some of them (disabling rules), but this is not ideal. We have 100s of projects and it is hard to manage.
A: By ‘rule exceptions’ do you mean crashing rules? Can you make sure that we know about these over on the Code Analysis forum (http://forums.microsoft.com/msdn/ShowForum.aspx?ForumID=98)? We have fixed a lot of these since 1.35, however, I want to make sure we fixed the ones you’ve encountered.