C Sharp Coding Style (edit)

  • ReSharper
  • CodeMaid

C# Coding Style · Azure/DotNetty Wiki · GitHub

C# at Google Style Guide | styleguide

Net Framework Design Guidelines

naming-convention/C# Coding Standards and Naming Conventions.md at master · ktaranov/naming-convention · GitHub

When editing files, keep new code and changes consistent with the style in the files. For new files, it should conform to the style for that component. Last, if there's a completely new component, anything that is reasonably broadly accepted is fine.

  1. We use Allman style braces, where each brace begins on a new line. Single line statement block must be enclosed in braces.
  2. We use four spaces of indentation (no tabs).
  3. We use lowerCamelCase for private fields and use readonly where possible. We don't use underscore (_) in field names.
  4. this. must always be specified when accessing instance member.
  5. We skip specifying visibility when it matches the default: private for class members and nested classes, internal for top-level classes, interfaces, structs and enums.
  6. Namespace imports should be specified within namespace scope and should be sorted alphabetically, with `System. namespaces at the top.
  7. Avoid more than one empty line at any time. For example, do not have two blank lines between members of a type.
  8. Avoid spurious free spaces. For example avoid if (someVar == 0)..., where the dots mark the spurious free spaces. Consider enabling "View White Space (Ctrl+E, S)" if using Visual Studio, to aid detection.
  9. If a file happens to differ in style from these guidelines, the existing style in that file takes precedence. Fixing style can be done separately and must not carry any functional changes.
  10. We only use var when it's obvious what the variable type is (i.e. var stream = new FileStream(...), not var stream = OpenStandardInput()).
  11. We use language keywords instead of BCL types (i.e. int, string, float instead of Int32, String, Single, etc) for both type references as well as method calls (i.e. int.Parse instead of Int32.Parse).
  12. We use PascalCasing to name all our constant local variables and fields. The only exception is for interop code where the constant value should exactly match the name and value of the code you are calling via interop.

We have provided a ReSharper settings file (DotNetty.sln.DotSettings) at the root of the repository, making it easier to follow the above guidelines when using Visual Studio with ReSharper. Use of ReSharper's Cleanup Code using supplied profile ("Simple") is welcome unless it affects non-trivial amount of otherwise unchanged code. In this case, separate PR, enforcing code styling should be posted.

C# Coding Standards and Naming Conventions

Object Name Notation Length Plural Prefix Suffix Abbreviation Char Mask Underscores
Namespace name PascalCase 128 Yes Yes No No [A-z][0-9] No
Class name PascalCase 128 No No Yes No [A-z][0-9] No
Constructor name PascalCase 128 No No Yes No [A-z][0-9] No
Method name PascalCase 128 Yes No No No [A-z][0-9] No
Method arguments camelCase 128 Yes No No Yes [A-z][0-9] No
Local variables camelCase 50 Yes No No Yes [A-z][0-9] No
Constants name PascalCase 50 No No No No [A-z][0-9] No
Field name camelCase 50 Yes No No Yes [A-z][0-9] Yes
Properties name PascalCase 50 Yes No No Yes [A-z][0-9] No
Delegate name PascalCase 128 No No Yes Yes [A-z] No
Enum type name PascalCase 128 Yes No No No [A-z] No

Source Code examples:

https://github.com/armancse100/ASP.NetCoreWithSignalR_and_SQLite/

https://github.com/cmatskas/ASP.NETCorewithKeyVaultAndMSI/

https://github.com/damienbod/AspNetCoreMultipleProject/

https://github.com/aspnet/SignalR-samples/tree/main/ChatSample/ChatSample/

https://github.com/oktadev/okta-aspnet-mvc-core-sqlite-example/

https://github.com/dotnet/aspnetcore/tree/main/src/SignalR/samples/

Source code examples for ASP.NET Core in Action, Second Edition

GitHub - andrewlock/asp-dot-net-core-in-action-2e: Source code examples for ASP.NET Core in Action, Second Edition