Coding standards
C# coding conventions
As a very first step in establishing a common code convention/standard, there’s the Microsoft C# code convention and Microsoft naming conventions. For naming of member and local variables, have a look at http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx..
It might not be suitable for a coding standard, but it’s always a good idea to keep the SOLID principles in mind when creating a new application.
Prefer strong typing to implicit declarations…? http://blogs.msdn.com/b/ericlippert/archive/2011/04/20/uses-and-misuses-of-implicit-typing.aspx
You should follow the ReSharper to check the coding guidelines. ReSharper will tell you right away if your code contains errors or can be improved. ReSharper warn you when there’s a problem in your code but it provides quick-fixes to solve them automatically.
You can easy to integrate SonarQube into the CI pipeline. SonarQube is one of many static code analysis tools.
Some of the coding standards are given below:
- Naming convention on methods, class variable, read-only variable: Code that is consistent is more maintainable
- Length of methods and class: Long and long classes makes it more difficult to understand and maintain code. Functions should be short and sweet, and do just one thing. Avoid files with more than 500 lines. Avoid methods with more than 200 lines. Lines should not exceed 120 characters. Avoid methods with more than 5 arguments. Use structures for passing multiple arguments
- Don’t Repeat Yourself: Which requires you to rigorously remove duplication in your code base. If you notice that you’re doing the same task again, try to generalize it in order to avoid duplicate code. It is frustrating to change the same error in several places
- Remove and sort imports: Unused imports makes it harder to read code and to remove unused references
- Is code covered by an automatic test: It doesn’t have to be a unit test. If component test is covering is OK. Trivial code doesn’t need to have unit-test