Braces are used with if
, else
, for
, do
, while
, etc. statements, even when the body is
empty or contains only a single statement.
Use Allman style braces, where each brace begins on a new line.
Each time a new block or block-like construct is opened, the indent increases by four spaces (not tabs). When the block ends, the indent returns to the previous indent level. The indent level applies to both code and comments throughout the block.
Limit lines to 120 characters when possible.
Terminology Note: When code that might otherwise legally occupy a single line is divided into multiple lines, this activity is called line-wrapping.
There is no comprehensive, deterministic formula showing exactly how to line-wrap in every situation. Very often there are several valid ways to line-wrap the same piece of code.
Note: While the typical reason for line-wrapping is to avoid overflowing the column limit, even code that would in fact fit within the column limit may be line-wrapped at the author's discretion.
Tip: Extracting a method or local variable may solve the problem without the need to line-wrap.
The prime directive of line-wrapping is: prefer to break at a higher syntactic level. Also:
- When a line is broken at a non-assignment operator the break comes before the symbol. This also
applies to the dot separator (
.
). - When a line is broken at an assignment operator the break typically comes after the symbol, but eitherway is acceptable.
- A method or constructor name stays attached to the open parenthesis (
(
) that follows it. - A comma (
,
) stays attached to the token that precedes it.
When line-wrapping, each line after the first (each continuation line) is indented at least +4 from the original line.
When there are multiple continuation lines, indentation may be varied beyond +4 as desired. In general, two continuation lines use the same indentation level if and only if they begin with syntactically parallel elements.
The list below shows the order in which members should appear in a class file.
- Public fields, properties and events
- Protected fields, properties and events
- Constructors
- Methods
- Private fields
- Nested types: public, internal, then private
Follow the names .NET Naming Guidelines. Some scenarios not covered by those guidelines are covered below.
The Framework Design Guidelines do not cover internal and private fields, so we cover them here.
✓ DO use the same guidelines as static public and protected fields for private/internal static/const fields.
✓ DO use camelCasing in private/internal instance field names.
✓ DO use the underscore (_
) prefix for private/internal instance field names.
For example: _position
, _length
, _capacity
(see MemoryStream.cs)
Use language keywords instead of BCL types (e.g. 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
).
We only use var
when it's obvious what the variable type is (e.g. var stream = new FileStream(...)
not var stream = OpenStandardInput()
).