C# specific standards

[michaelachrisco]

I don't currently see any C# related docs in the repo.

I am thinking somewhere in: https://github.com/Shift3/standards-and-practices/tree/master/best-practices/server-side/framework/dotnet

Related to #65

[Karvel]

I think we should chat about this. There is already a @Shift3/devs-dotnet organization team. I've got some ideas more for .NET Core patterns and tooling than C# in general. I know Corey does as well.

[michaelachrisco]

@Karvel Absolutely, I have some thoughts, mostly just clean code kind of patterns etc... There are C# specific ones that may work better for the env but I would rather get everyones thoughts before we start on actually changing what we already have.

[coreyshuman]

So we're in the awkward position where we've pretty much never really done any .NET projects from scratch at Shift3 (exception Sinclair), we're always inheriting and maintaining legacy software from clients or working in staff augmentation settings where we follow the client's standards. That said, once we get around to the .NET server boilerplate, that will be a great opportunity to start developing some best practices.

[HansHKam]

Do we need standards such as a variable naming convention or more like code structuring?
I recently watched an episode of Silicon Valley about spaces vs tabs, it convinced me that spaces are inferior to tabs.

[michaelachrisco]

Do we need standards such as a variable naming convention or more like code structuring?
Great question. Im thinking that variable naming convention might be good to discuss and figure out. What does Microsoft themselves recommend?

I recently watched an episode of Silicon Valley about spaces vs tabs, it convinced me that spaces are inferior to tabs.

Its a good show. A little too real sometimes haha.
I also prefer spaces, but as far as a specific standard, im thinking as long as the project is consistent, its good. Since a majority of our .Net projects are pulled in from existing outside client work, im thinking it would make more sense to keep with whatever standard they are using within their code...within reason. If they use both, then yeah we should totally standardize.

[Karvel]

I agree. Fighting over spaces versus tabs is a waste of time. It's a religious fight and people basically don't change their minds. The project should use what it's already using. If it's a new project or the project needs to consolidate two clashing indentation choices, the lead can choose. It's not personal code so if the choice doesn't line up with a personal choice it doesn't matter.

I've taken to wiring up an extremely opinionated linter in my JS projects that runs as a pre-commit hook. I don't actually like some of its style decisions, but this way nobody on the project needs to worry about style, and the pre-commit hook ensures that all commits apply the linting.

That scene is one of my favorites from the show though.