Standard C# coding conventions in project templates?

[agoodwin]

Hi,

I realise there are much bigger jobs that need doing in this SDK, and thanks for all of the work getting WinUI 3+ out the door so far, but after wanting to try out WinUI 3 for quite a while I immediately noticed something out of place in the auto-generated code of the project templates.

Basically, what I am talking about is this kind of private member naming from the C# templates:

private Window m_window;

According to standard C# conventions, a private member like this should probably be something like _mainWindow instead.

Of course, those guidelines don't have to be followed, and for this repo there aren't any public coding guidelines in place yet. However, because these C# templates are for Microsoft.UI.Xaml/WinUI projects, and the guidelines for that repo basically say to follow the standard C# conventions, it seems to me that the WinUI 3 project template code should probably follow those too.

I'm mainly looking at this from the perspective of a new developer coming into Windows/C# desktop development for the first time. I would imagine they're probably going to look at the boilerplate code of these templates and then think that's just how things are done – but actually that's generally not the case and so naming conventions like that are going to immediately send them off down the wrong path.

For me this pretty minor because in our company we can of course just rename the variables to match our conventions which generally follow the typical C# conventions. But if this the kind of thing that can just be slipped into a future update with minimal bureaucracy, does one of the maintainers of this repo agree it's worth doing?

Thanks again for the work on WinUI 3 and project reunion. I am looking forward to being able to migrate our main WPF app to this, hopefully not too far into the future.

[wjk]

Unfortunately, Microsoft is not accepting fixes for this problem (cf #622). I don't know why.

[saint4eva]

Project Reunion is for c++ developers. C# support is an after-thought. So, do not expect to receive all the .NET and C# love you are used to enjoying.