These are my C# Coding Guidelines. Feel free to use it.

 

Exception Handling

do not catch general exception. Always catch specific exceptions.

Why: generally accepted practice.


 

Declaration

do not declare member variables public. They should be exposed by a property if needed public access

Why: generally accepted practice.


 

do use implicit type var for local variable declarations when it makes sense.

Why: removes clutter, particularly with complex generic types. Type is easily detected with Visual Studio tooltips.


 

 

Comments

do use comment on public methods to describe what the method is doing. Keep it short

Why : So that a person who is going to use the method knows what the method is doing.


 

do not overuse comments in code. Better choose good names for variables, methods and classes.

Why: generally accepted practice.


 

 

Naming

do not use regions in code.

Why: regions are a sign of a bad class design and is an antipattern , not following best practices. regions are also a kind of code smell.


 

do use PascalCasing for class names and method names.

Why : consistent with the Microsoft’s .NET Framework and easy to read.


 

do use camelCasing for method arguments, local variables and private identifiers

Why: consistent with the Microsoft’s .NET Framework and easy to read.


 

do not use Hungarian notation or any other type identification in identifiers.

Why: consistent with the Microsoft’s .NET Framework and Visual Studio IDE makes determining types very easy (via tooltips). In general you want to avoid type indicators in any identifier.


do not use Screaming Caps for constants or readonly variables

Why: consistent with the Microsoft’s .NET Framework. Caps grap too much attention.


 

avoid using Abbreviations. Exceptions: abbreviations commonly used as names, such as Id, Xml, Ftp, Uri

Why: consistent with the Microsoft’s .NET Framework and prevents inconsistent abbreviations.


 

do use PascalCasing for abbreviations 3 characters or more (2 chars are both uppercase)

Why: consistent with the Microsoft’s .NET Framework. Caps would grap visually too much attention.


 

do not use Underscores in identifiers

Why: consistent with the Microsoft’s .NET Framework and makes code more natural to read (without ‘slur’). Also avoids underline stress (inability to see underline). Private identifiers can be also used with this.registrationDate


 

do use predefined type names instead of system type names like Int16, Single, UInt64, etc

Why: consistent with the Microsoft’s .NET Framework and makes code more natural to read.


 

do use noun or noun phrases to name a class.

Why: consistent with the Microsoft’s .NET Framework and easy to remember.


 

do prefix interfaces with the letter I. Interface names are noun (phrases) or adjectives.

Why: consistent with the Microsoft’s .NET Framework.


 

do name source files according to their main classes. Exception: file names with partial classes reflect their source or purpose, e.g. designer, generated, etc.

 

Why : consistent with the Microsoft practices. Files are alphabetically sorted and partial classes remain adjacent.


 

do use singular names for enums. Exception: bit field enums.

Why: consistent with the Microsoft’s .NET Framework and makes the code more natural to read. Plural flags because enum can hold multiple values (using bitwise ‘OR’).


 

do not explicitly specify a type of an enum or values of enums (except bit fields)

Why: can create confusion when relying on actual types and values.


 

do not suffix enum names with Enum

Why: consistent with the Microsoft’s .NET Framework and consistent with prior rule of no type indicators in identifiers.


 

Formatting

do organize namespaces with a clearly defined structure

Why: consistent with the Microsoft’s .NET Framework. Maintains good organization of your code base.


do vertically align curly brackets

Why: Microsoft has a different standard, but developers have overwhelmingly preferred vertically aligned brackets.


 

do declare all member variables at the top of a class, with static variables at the very top and private above the publlic static.

Why: generally accepted practice that prevents the need to hunt for variable declarations.


 

 

 

 

 

 

C# Coding Guidelines
Tagged on:     

Leave a Reply

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers:

Welcome Damir Kusar

Log in

Lost your password?
%d bloggers like this: