Nice post. But I think that the most critical is control flexibility, customization and easy to use. So there should be some sort of guidelines declare rules to make control flexible, customizable and easy to use.

Let’s take a look at DataForm control as an example:

1. Why dataform holds buttons (add,delete,next,prev) inside it? It is much more simpler to declare that buttons in view and have full control under them. Dataform take collection of items instead of single item. It is very easy to implement next and prev feature without build in support. All this make the control very complex. It has thousands of codelines. Is it easy to use? NOT!
2. Dataform hardcodes generated controls for displaying fields by their data type. What if I want to display datetime with TelerikCalendar? What if want to display int with Slider for propertyX and with textBox for propertyY? As a result form autogeneration is useless in most of cases.

Thanks,
Alexey Zakharov.

I am all for any guideline that helps me to write more reliable and easier to maintain code.

One of the things that I do which I don’t see many other developers doing is using prefixes to help identify a variables scope. I love Intellisense; however, one simply does not mouse over ever variable while developing – it can be very easy to assume a variable has one scope when it actually has another which can be disastrous.

The specific method for indicating scope is a question of taste but I do think it is important to do – for example, some of the scope prefixes that I use are: m_ – fields, p_ – passed in parameters, s_ – statics, etc.

To me when I look at a variable I want to instantly be able to tell it’s scope, it’s type, and a clear description of it’s purpose – yea, I know Intellisense will tell me a lot but like I said, we simply do not mouse over every variable and it is very easy to assume the wrong thing.

Anyway, it’s just my style.

Thanks for the guidelines,
David

Like I told you on Twitter, I cannot remember why I deactivated some of the rules, but left the “this.” rule. I am reconsidering this.

For the ordering, I do like to order my methods (I use Resharper’s functionality to do this) however I wish I could enforce ordering for all members except those belonging to a DP (accessors, private attribute, etc…). Failing to do so, I decided to just avoid using regions altogether.

Cheers,
Laurent

More details here: http://blogs.msdn.com/sourceanalysis/pages/sharing-source-analysis-settings-across-projects.aspx

I’ll send or publish the settings file we use on the Silverlight Toolkit if you like, btw.

- Grouping DPs in regions will cause it to protest because you don’t follow the rule of ordering methods and properties.

- Stylecop requires the use of “this”. I am not a big fan of using this in front of local params/methods/properties, but started doing it because I am tired of the Stylecop warning. I use Resharper to format my code, so it’s not a big deal.

I went back and forth on the use of Stylecop. The best solution would be to be able to ceate our own rules (like FxCop allows) or at least to switch some rules off. Unfortunately it is not possible.

Cheers,
Laurent

Good advice on the rest though – esp. naming. I guess I’m just sharing my perspective here, coding style and guidelines are a holy war for some, so “When in Rome” is probably the best advice – follow peers and the team’s practices and not some dude’s blog

For the IList vs array: Perhaps this isn’t the best example, since an IList indicates need for dynamic Add/Remove capabilities, something an array won’t have. I suppose the better advice is to return an IEnumerable before an array, if possible.

Chris Anderson

public event RoutedEventHandler DownloadProgressChanged;

private void OnDownloadProgressChanged(object sender, RoutedEventArgs args)
{
if (!Dispatcher.CheckAccess())
{
Dispatcher.BeginInvoke(() => OnDownloadProgressChanged(sender, args));
return;
}

var handler = DownloadProgressChanged;
if (handler != null)
{
handler(this, args);
}
}

Two questions:

- Why not just fire the event in Dispatcher instead of calling yourself?

- Why do you get a local copy of the handler to check for null? Why not just check the handler directly?