Coding style

[jarnmo]

Let's try to find a best-practice coding style for windows apps. Let's start by finding different C# and xaml coding styles already defined. You can also come up with a style or explain a detail you would like to see in the style.

It seems like StyleCop is pretty much the defacto open source way to define coding styles in Visual Studio and MSBuild, so it would be good if the links posted here would also point to a StyleCop style.

Feel free to discuss the styles and let's try to settle with one that should go into the best-practices.

[DenisAnchugov]

Here is what Microsoft suggests: https://msdn.microsoft.com/en-us/library/ms229042.aspx
A book that was brought by one of the teams in Microsoft. Might be useful: http://1code.codeplex.com/wikipage?title=All-In-One%20Code%20Framework%20Coding%20Standards

[pingzing]

As for actual StyleCop integration, it appears that as of VS2015, StyleCop no longer supports Visual Studio, presumably due to the Roslyn overhaul. However, the StyleCopAnalyzers project seems to exist to fill that gap.

[jarnmo]

There's also Visual StyleCop for VS 2015

[jarnmo]

CodeMaid can also do some reorganizing according to StyleCop rules. There's a trello board backlog which mentions possible rewrite for Roslyn.

[jarnmo]

And here's the CoreFx coding style document and a Roslyn based tool they are using.

[jarnmo]

After some face-to-face discussions it has become pretty clear that it would be difficult to agree on any actual coding style as a best practice for windows apps. However the StyleCopAnalyzer seems like an extremely promising tool for enforcing and helping to maintain a project specific coding style.

It comes with a reasonable base set of rules, but I noticed some I don't really agree with:

1. Fields not prefixed with underscore

I like to prefix fields with an underscore so it's obvious when ever a field is used in code. A field should usually only be used in very specific places of a class and incorrect usage usually leads to possibly hard to debug bugs. One case being backing fields for properties. The field should only be used within the property setter and getter, but it's easy to make the mistake of using propertyname instead of Propertyname. Additionally, with the underscore prefix, if you want to set a (constructor) parameter into a field you don't need to use 'this' for the field.

2. Requiring prefixing field and property usages with 'this.'

With the conventions of _field, local, and Property, you never need to litter your code with 'this.' prefixes. MyMethod(this.Property, this.field, local) just isn't as clean as MyMethod(Property, _field, local)

3. Explicit scope declarations not required

The default scope varies from programming language to another. To avoid mistakes and to add extra readability I just like to add the explicit scope declaration even if matches the default scope.

4. Requiring opening brace of a multi-line statement to be on their own line

With the default StyleCop style a lot of lines on your screen contain a single brace. Having each closing brace on it's own line is definitely more readable than having them on the end of the last line of the block. However, having the opening braces on their own lines doesn't really add readability, as the first line of the scope will be intended anyway. Less brace-only lines means more lines of actual code on your screen, which means less navigation around a code file is required.

5. Closing parenthesis must be placed on the same line with the last parameter on multi-line parameter lists

Placing the closing parenthesis on it's own line on multi-line parameter lists seems more readable to me. For example:

Method(
    param1,
    statementWithClosingParenthesis()
)

vs

Method(
    param1,
    statementWithClosingParenthesis())