Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/a-patel/csharp-style-guide
C# Style Guide for Tutorials
https://github.com/a-patel/csharp-style-guide
coding-standards csharp microsoft style-guide styleguide
Last synced: 1 day ago
JSON representation
C# Style Guide for Tutorials
- Host: GitHub
- URL: https://github.com/a-patel/csharp-style-guide
- Owner: a-patel
- License: mit
- Created: 2018-09-12T07:52:14.000Z (over 6 years ago)
- Default Branch: master
- Last Pushed: 2018-09-12T16:38:05.000Z (over 6 years ago)
- Last Synced: 2024-11-24T19:14:36.576Z (2 months ago)
- Topics: coding-standards, csharp, microsoft, style-guide, styleguide
- Size: 25.4 KB
- Stars: 2
- Watchers: 3
- Forks: 2
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# C# Style Guide
C# Style Guide for Tutorials
---
The code is read much more often than it is written.
### The Zen of any programming language
* Beautiful is better than ugly.
* Explicit is better than implicit.
* Simple is better than complex.
* Complex is better than complicated.
* Flat is better than nested.
* Sparse is better than dense.
* Readability counts.
* Special cases aren't special enough to break the rules.
* Although practicality beats purity.
* Errors should never pass silently.
* Unless explicitly silenced.
* In the face of ambiguity, refuse the temptation to guess.
* There should be one-- and preferably only one --obvious way to do it.
* Although that way may not be obvious at first unless you're Dutch.
* Now is better than never.
* Although never is often better than *right* now.
* If the implementation is hard to explain, it's a bad idea.
* If the implementation is easy to explain, it may be a good idea.
* Namespaces are one honking great idea -- let's do more of those!
You also see "Readability Counts" in the above listed points, which should be your main concern while writing code: other programmers should understand and should be able to contribute to your code so that it can solve the task at hand.
## Style Guiding Principles
* Be consistent.
* Don't rewrite existing code to follow this guide.
* Don't violate a guideline without a good reason.
* A reason is good when you can convince a teammate, not just when you like it.
* Assume your reader knows C# and English.
* Prefer clarity to 'performance'.
* Prefer clarity to .NET dogma.
* Write comments that people want to read, with correct spelling and grammar.
## The Rundown
* Indent with tabs.
* Max line length is 100 columns.
* Use spaces and empty lines precisely.
* Braces generally go on their own lines.
* Never put a space before `[`.
* Always put a space before `{`.
* Always put a space before `(` except for method invocations or when following another `(`.
## Table of Contents
- [Nomenclature](#nomenclature)
+ [Namespaces](#namespaces)
+ [Classes & Interfaces](#classes--interfaces)
+ [Methods](#methods)
+ [Fields](#fields)
+ [Parameters](#parameters--parameters)
+ [Delegates](#delegates--delegates)
+ [Events](#events--events)
+ [Misc](#misc)
- [Declarations](#declarations)
+ [Access Level Modifiers](#access-level-modifiers)
+ [Fields & Variables](#fields--variables)
+ [Classes](#classes)
+ [Interfaces](#interfaces)
- [Spacing](#spacing)
+ [Indentation](#indentation)
+ [Line Length](#line-length)
+ [Vertical Spacing](#vertical-spacing)
- [Brace Style](#brace-style)
- [Switch Statements](#switch-statements)
- [Language](#language)
- [Copyright Statement](#copyright-statement)
- [Smiley Face](#smiley-face)
- [Credit](#credits)
## Nomenclature
On the whole, naming should follow C# standards.
### Namespaces
Namespaces are all **PascalCase**, multiple words concatenated together, without hypens ( - ) or underscores ( \_ ):
**BAD**:
```csharp
com.raywenderlich.fpsgame.hud.healthbar
```
**GOOD**:
```csharp
RayWenderlich.FpsGame.Hud.Healthbar
```
### Classes & Interfaces
Written in **PascalCase**. For example `RadialSlider`.
### Methods
Methods are written in **PascalCase**. For example `DoSomething()`.
### Fields
All non-static fields are written **camelCase**. Per Unity convention, this includes **public fields** as well.
For example:
```csharp
public class MyClass
{
public int publicField;
int packagePrivate;
private int myPrivate;
protected int myProtected;
}
```
**BAD:**
```csharp
private int _myPrivateVariable
```
**GOOD:**
```csharp
private int myPrivateVariable
```
Static fields are the exception and should be written in **PascalCase**:
```csharp
public static int TheAnswer = 42;
```
### Parameters
Parameters are written in **camelCase**.
**BAD:**
```csharp
void DoSomething(Vector3 Location)
```
**GOOD:**
```csharp
void DoSomething(Vector3 location)
```
Single character values are to be avoided except for temporary looping variables.
### Delegates
Delegates are written in **PascalCase**.
When declaring delegates, DO add the suffix **EventHandler** to names of delegates that are used in events.
**BAD:**
```csharp
public delegate void Click()
```
**GOOD:**
```csharp
public delegate void ClickEventHandler()
```
DO add the suffix **Callback** to names of delegates other than those used as event handlers.
**BAD:**
```csharp
public delegate void Render()
```
**GOOD:**
```csharp
public delegate void RenderCallback()
```
### Events
Prefix event methods with the prefix **On**.
**BAD:**
```csharp
public static event CloseCallback Close;
```
**GOOD:**
```csharp
public static event CloseCallback OnClose;
```
### Misc
In code, acronyms should be treated as words. For example:
**BAD:**
```csharp
XMLHTTPRequest
String URL
findPostByID
```
**GOOD:**
```csharp
XmlHttpRequest
String url
findPostById
```
## Declarations
### Access Level Modifiers
Access level modifiers should be explicitly defined for classes, methods and member variables.
### Fields & Variables
Prefer single declaration per line.
**BAD:**
```csharp
string username, twitterHandle;
```
**GOOD:**
```csharp
string username;
string twitterHandle;
```
### Classes
Exactly one class per source file, although inner classes are encouraged where scoping appropriate.
### Interfaces
All interfaces should be prefaced with the letter **I**.
**BAD:**
```csharp
RadialSlider
```
**GOOD:**
```csharp
IRadialSlider
```
## Spacing
Spacing is especially important in raywenderlich.com code, as code needs to be easily readable as part of the tutorial.
### Indentation
Indentation should be done using **spaces** — never tabs.
#### Blocks
Indentation for blocks uses **4 spaces** for optimal readability:
**BAD:**
```csharp
for (int i = 0; i < 10; i++)
{
Debug.Log("index=" + i);
}
```
**GOOD:**
```csharp
for (int i = 0; i < 10; i++)
{
Debug.Log("index=" + i);
}
```
#### Line Wraps
Indentation for line wraps should use **4 spaces** (not the default 8):
**BAD:**
```csharp
CoolUiWidget widget =
someIncrediblyLongExpression(that, reallyWouldNotFit, on, aSingle, line);
```
**GOOD:**
```csharp
CoolUiWidget widget =
someIncrediblyLongExpression(that, reallyWouldNotFit, on, aSingle, line);
```
### Line Length
Lines should be no longer than **100** characters long.
### Vertical Spacing
There should be exactly one blank line between methods to aid in visual clarity
and organization. Whitespace within methods should separate functionality, but
having too many sections in a method often means you should refactor into
several methods.
## Brace Style
All braces get their own line as it is a C# convention:
**BAD:**
```csharp
class MyClass {
void DoSomething() {
if (someTest) {
// ...
} else {
// ...
}
}
}
```
**GOOD:**
```csharp
class MyClass
{
void DoSomething()
{
if (someTest)
{
// ...
}
else
{
// ...
}
}
}
```
Conditional statements are always required to be enclosed with braces,
irrespective of the number of lines required.
**BAD:**
```csharp
if (someTest)
doSomething();
if (someTest) doSomethingElse();
```
**GOOD:**
```csharp
if (someTest)
{
DoSomething();
}
if (someTest)
{
DoSomethingElse();
}
```
## Switch Statements
Switch-statements come with `default` case by default (heh). If the `default` case is never reached, be sure to remove it.
**DEFAULT GETS USED:**
```csharp
switch (variable)
{
case 1:
break;
case 2:
break;
default:
break;
}
```
**DEFAULT DOESN'T GET USED:**
```csharp
switch (variable)
{
case 1:
break;
case 2:
break;
}
```
## Language
Use US English spelling.
**BAD:**
```csharp
string colour = "red";
```
**GOOD:**
```csharp
string color = "red";
```
Indentation
Maximum Line Length
Line Wraps
Blank Lines
Whitespaces in Expressions and Statements
Imports/usings/regions
Comments
Naming Conventions
links
https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/index
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions
https://www.dofactory.com/reference/csharp-coding-standards