standards-c-sharp

Guiding principle: Simplicity over complexity.

Keep It Simple, Stupid - Some guy

Project structure and design

• Keep web solution structure simple

Service design

• Service design guide
• Do not depend on framework abstractions
• Avoid constructor over injection

IoC

• Register dependencies using attributes
• Do not use stereotype-style registrations

Method design

Static and instance methods

• Prefer pure static methods over instance
• When to write a static method
• When to write an instance method

Extension methods

• General guidance
• When (and when not) to write an extension method

Exceptions

Throwing exceptions

• Fail as quickly and as loudly as possible
• Only throw exceptions in exceptional circumstances

Catching exceptions

• Be specific in what you catch
• Only catch exceptions with good reason
• Make use of the global exception handler

Swallowing exceptions

• Critical vs non-critical exceptions
• Don’t swallow exceptions unless you can gracefully recover

Rethrowing exceptions

• How to rethrow an exception from a catch block
• Rethrow exceptions when you cannot gracefully recover

Testing

• Why we test
• Follow the testing pyramid
• Test method names should clearly indicate what they are testing
• Write tests as if they are a specification

Unit tests

• Unit tests should be short and simple
• Use test cases appropriately
• Keep app functions pure if possible
• Be wary of refactoring tests
• Prefer black box over white box testing
• Only test the public interface
• Create reusable concrete mocks
• Consider using AutoFixture
• Further reading

GUI and E2E tests

• Use a Page Object to interact with your app
• Use the data-selenium attribute to identify your elements
• Use CSS-selectors instead of XPath to access elements

Collections

Choosing the correct collection type

• Choosing the correct type for an enumerable
• Collections on public APIs
• Collections on non-public API methods
• Do not use Arrays, except…
• Queues
• IQueryable
• Immutable collections
• Using reference types as keys

General

• Do not return null to represent an empty enumerable
• Do not check for presence of elements before enumerating a collection

Asynchronous programming

• Avoid blocking when possible
• Always use the asynchronous version of a method when it exists
• Do not expose both sync and async versions of methods
• Avoid mixing synchronous and asynchronous code
• Return Task instead of void for async methods with no return value
• Use await task instead of task.Result
• Never use Task.Wait
• Use await Task.WhenAny/All instead of Task.WaitAny/All
• Prefer to start tasks with Task.Run
• Use await instead of Task.ContinueWith
• Avoid unnecessary use of async modifier
• Avoid race conditions with proper synchronization
• Correct use of ConfigureAwait(false)

Reflection

• Do not use hard coded string to identify types

Code style

• Naming conventions
• Do not (explicitly) use monads
• Do not use dynamic
• Do not use #region

Configuration

• If it’s unlikely to change, don’t make it configurable
• Using Consul
• Use config files only for Consul client settings and sensitive data
• Use Consul’s service discovery for server addresses
• Use Consul’s Key/Value store for anything else
• Do not use MachineName to configure the application

Strings

• For string operations, always explicitly specify comparison/culture rules

Routing

• Use attribute-based routing instead of convention-based routing

Logging

• Logging
• Log levels

This site is open source. Improve this page.