The general rule we follow is “use Visual Studio defaults”.
using statement is permitted to be nested within another using statement by starting on the following line at the same indentation level, even if the nested using contains a controlled block._camelCase for internal and private fields and use readonly where possible. Prefix internal and private instance fields with _, static fields with s_ and thread static fields with t_. When used on static fields, readonly should come after static (e.g. static readonly not readonly static). Public fields should be used sparingly and should use PascalCasing with no prefix when used.this. unless absolutely necessary.private string _foo not string _foo). Visibility should be the first modifier (e.g.
public abstract not abstract public).namespace declarations, and should be sorted alphabetically, with the exception of System.* namespaces, which are to be placed on top of all others.if (someVar == 0)..., where the dots mark the spurious free spaces.
Consider enabling “View White Space (Ctrl+R, Ctrl+W)” or “Edit -> Advanced -> View White Space” if using Visual Studio to aid detection.m_member
rather than _member), the existing style in that file takes precedence.var when the type is explicitly named on the right-hand side, typically due to either new or an explicit cast, e.g. var stream = new FileStream(...) not var stream = OpenStandardInput().
new() can only be used when the type is explicitly named on the left-hand side, in a variable definition statement or a field definition statement. e.g. FileStream stream = new(...);, but not stream = new(...); (where the type was specified on a previous line).int, string, float instead of Int32, String, Single, etc) for both type references as well as method calls (e.g. int.Parse instead of Int32.Parse). See issue #13976 for examples.nameof(...) instead of "..." whenever possible and relevant.if (source == null) throw new ArgumentNullException("source");)if/else if/…/else compound statement uses braces or if a single statement body spans multiple lines.if/else if/…/else compound statement is placed on a single line.An EditorConfig file (.editorconfig) has been provided at the root of the runtime repository, enabling C# auto-formatting conforming to the above guidelines.
We also use the dotnet-format tool to ensure the code base maintains a consistent style over time, the tool automatically fixes the code base to conform to the guidelines outlined above.
ObservableLinkedList`1.cs:
using System;
using System.Collections;
using System.Collections.Generic;
using System.Collections.Specialized;
using System.ComponentModel;
using System.Diagnostics;
using Microsoft.Win32;
namespace System.Collections.Generic
{
public partial class ObservableLinkedList<T> : INotifyCollectionChanged, INotifyPropertyChanged
{
private ObservableLinkedListNode<T> _head;
private int _count;
public ObservableLinkedList(IEnumerable<T> items)
{
if (items == null)
throw new ArgumentNullException(nameof(items));
foreach (T item in items)
{
AddLast(item);
}
}
public event NotifyCollectionChangedEventHandler CollectionChanged;
public int Count
{
get { return _count; }
}
public ObservableLinkedListNode AddLast(T value)
{
var newNode = new LinkedListNode<T>(this, value);
InsertNodeBefore(_head, node);
}
protected virtual void OnCollectionChanged(NotifyCollectionChangedEventArgs e)
{
NotifyCollectionChangedEventHandler handler = CollectionChanged;
if (handler != null)
{
handler(this, e);
}
}
private void InsertNodeBefore(LinkedListNode<T> node, LinkedListNode<T> newNode)
{
...
}
...
}
}
ObservableLinkedList`1.ObservableLinkedListNode.cs:
using System;
namespace System.Collections.Generics
{
partial class ObservableLinkedList<T>
{
public class ObservableLinkedListNode
{
private readonly ObservableLinkedList<T> _parent;
private readonly T _value;
internal ObservableLinkedListNode(ObservableLinkedList<T> parent, T value)
{
Debug.Assert(parent != null);
_parent = parent;
_value = value;
}
public T Value
{
get { return _value; }
}
}
...
}
}
For other languages, our current best guidance is consistency. 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. If there is a completely new component, anything that is reasonably broadly accepted is fine. For script files, please refer to the scripting blog for tips and best practices.