Consistent C# coding styles in .NET Core and VS 2019

Are you a part of champion C# team who has developers from Different background (JavaScript, Python, Java, Ruby etc.)?

Some of them may prefer their own ways of indentations, placing curly brace locations (JavaScriptish), even not putting them at all (Python-ish).

Curly Brace Conventions by the JavaScript community.
But, C# community prefers that the opening or closing brace within a C# statement, element, or expression should be placed on its own line.

Members from your team have different perspectives over C# coding styles however your team want everyone to follow agreed guideline as if code is written by a single developer and it’s readable?

Are you tired of seeing/receiving linting comments in the C# code reviews?

Multiple violations: Space required after if and closing parenthesis, Extra parenthesis

Do you want to automatically find and fix those as a part of C# code self-reviews?

Omission of curly brace introduced a serious bug. return Buzz will gets always executed.

remove unused variables, remove unused methods, remove unused namespaces and MANY MORE.

Answer to these questions are combination of tools:

  • .EditorConfig
  • StyleCop

If you have a single or multiple project make sure you create a .editorconfig at root level (Solution level) so that all the rules are applicable to all the projects under a solution.


  • Open your project solution in the visual studio 2019.
  • Right click on your solution file

A solution with multiple projects (For you it could be 10 or 100 projects)

  • Click on New EditorConfig. It will create a file with pre-configured rules.

  • Install StyleCopAnalyzers using the NuGet command line or the NuGet Package Manager in Visual Studio 2019 for all the projects.

  • Right click on solution and Click build. Now it will start showing fixable things as warnings in your IDE’s “Error List” window.
Error List window in the visual studio showing fixable warnings.

Raise the bar

You can even push yourself and set few rules as errors in the .editorconfigs

Option from IDE to set some guideline as Error and other options.
Set obvious suggestions as an error and some as none to reduce the noise.

Do you want to try it before applying it to your project?

Here is the git repo link:

Primitive Obsession – The code smell

Programming languages divide their types mainly into two categories.

  • Primitive types (A built-in types like string, boolean, int, decimal…)
  • Objects (class/function): User-defined types using class-based/prototype-based objects.

A primitive data type is a data type for which the programming language provides built-in support. Example: number, string, boolean, date and so on.

There are situations when developers should represent their idea/concept using user-defined types (Abstraction or encapsulation).

Whereas they choose to use primitive types (inbuilt int, string…) to represents the concept.

“Talk is cheap. Show me the code.” ― Linus Torvalds

Consider the above API for scheduling meetup.

If you observe carefully, all the parameters: topic, description, date, location id, and max participants when they stand together represent the concept/idea called meetup.

Almost all the data types are primitive types (Built-in types: string, int, DateTime and so on).


Overutilization of these primitive types to solve a problem makes the code more verbose/procedural and logic to deal with them is scattered.


Since all method parameter stands together to represent the concept called Meetup.

Here, we could group all these parameters together to represent the idea/concept called meetup. So, introduce an object to gather these data values.

Upon replacing data values with an object API would look like:

This is how the API should have been. However, the developer chooses to go with all built-in types (segregated). IMO, this overutilization of primitive types in almost all cases can be treated as an obsession about primitives which can be called a primitive obsession.

I have explained only one scenario and there are other scenarios too.