If anything interesting is announced or discussed, I’ll try to blog about it here.

John discusses the differences between Silverlight and WPF regarding control templates which I’ve mentioned in the past. Sounds like in Beta 2 they are making some more changes — yet still not feature compatible with WPF. No triggers. Bleck. Triggers with setters rock and give designers simple power. Maybe what he’s talking about is better in some way — but it still doesn’t sound like a trigger. :(

I don’t get it.

Maybe it will become clear as the series progresses, but the idea of a powershell cmdlets, etc. powering a WPF front end doesn’t make sense to me.

I thought the whole idea idea of Powershell was that it was a shell plaform — an advanced command prompt?

Instinctively, I think — no GUI. Mixing WPF and Powershell together feels somehow wrong, like using a mud topping on a bowl of ice cream.

Nonetheless, here’s the start of the series. The first post suggests it will be a “7 day” series.

WPF & PowerShell – Part 1 ( Hello World & Welcome to the Week of WPF )

WPF & PowerShell – Part 2 (Exploring WPF (and the rest of .NET) with Scripts)

WPF & PowerShell — Part 3 (Handling Events)

Do you use the Powershell? I’ve tried it — and never gotten far as it’s just not solving a problems I encounter regularly.

From Microsoft….

Source Analysis is similar in many ways to Microsoft Code Analysis (specifically FxCop), but there are some important distinctions. FxCop performs its analysis on compiled binaries, while Source Analysis analyzes the source code directly. For this reason, Code Analysis focuses more on the design of the code, while Source Analysis focuses on layout, readability and documentation. Most of that information is stripped away during the compilation process, and thus cannot be analyzed by FxCop.

The ultimate goal of Source Analysis is to allow you to produce elegant, consistent code that your team members and others who view your code will find highly readable. In order to accomplish this, Source Analysis does not allow its rules to be very configurable. Source Analysis takes a one-size-fits-all approach to code style, layout, and readability rules. It is highly likely that you will not agree with all of the rules and may even find some of the rules annoying at first! However, the majority of teams using this tool within Microsoft have found that after a short adjustment period, they came to appreciate the rules enforced by Source Analysis, and even began to find it difficult to read code not written in this style. 

Source Analysis comes with a set of default rules analyzers covering approximately 200 best practice rules. These rules are full compatible with the default layout settings in Visual Studio 2005 and Visual Studio 2008.

I’ve downloaded it and tried it on a project I was working on for home.

In a 428 line CS file, I had only 148 violations. :)

A few of them I’m a bit surprised by I suppose, like the requirement that function calls must be prefixed with this. 

“A comment may not be placed within the bracketed statement” and “A line may only contain a single statement”:

  } // catch
catch { }
} // attachment loop

OK, I’ll give them the catch is a bit odd (my code just gobbles any exceptions), but I don’t know that I understand why I can’t put a comment after a bracket (it’s just marking the end of a block).

“All using directives must be placed inside of the namespace.”

Eh? Why?

“Variable names must not start with m_”

Got that one wrong, I occasionally use s_ to indicate static instance fields. It’s misfiring on that one.

“Field names must not start with an underscore.”

Yeah, OK. No thanks. I like doing that and I’m not about to switch to prefixing everything with “this.” instead of an underscore. Bzzzt.

“An opening curly bracket must not be followed by a blank line.”

Oh my heavens! A blank line after a curly bracket?

Seriously though — if you’re wanting a rigorous source code formatting analysis tool, check this out. If you buy into all of their rules — it’s all good. If you don’t follow all of Microsoft’s C# conventions (some which I wasn’t aware of), then you may be in for a rude awakening.

Unfortunately, the thing that I’d like to have as a feature would be for it to optionally FIX the code to match the rules. Especially the easy stuff like blank lines and curly braces. I wouldn’t want it to touch variable names, etc. But the simple stuff … (oooh, and if it could rearrange the methods to be in the suggested order, like statics first, etc…..!!).