In order to become good programmers, we need to use a consistent coding style. When our code is consistent, we can focus on what the code does instead of how it's written. Errors are more apparent when debugging and it's easier to collaborate with other developers.

Here are some general C# coding guidelines to follow from the dotnet/corefx Coding Style documentation:

Indentation and Spacing

---

• Each brace should begin on a new line. This is called Allman Style. A single line statement block can go without braces but the block must be properly indented on its own line and must not be nested in other statement blocks that use braces.
• Avoid more than one empty line at any time. For example, do not have two blank lines between members of a type.
• Avoid free spaces. For example, avoid if (someVar == 0) . . ., where the dots mark the extra free spaces.
• Be consistent in your use of indentation. At Epicodus, we use two spaces of indentation while the .NET documentation recommends four spaces of indentation. There are advantages to both approaches. One advantage of two spaces is that a line of code is less likely to run past the width of a text editor. An advantage of four spaces is that some developers believe it's easier to read. Ultimately, it's a matter of preference - and being consistent with the standards of your workplace. At Epicodus, use two spaces unless you and your pair agree to use four. (You may use either two or four on independent projects.)

Capitalization and Naming

---

• Use camelCase for all method parameters and local variables.
• Use PascalCase for all public field names, class names, and method names.
• Prepend an underscore _ and use camelCase for all private field names.

Other Conventions

---

• Always specify the visibility, even if it is the default. For example, we should say private string Description, not string Description.
• Always declare the variable type, including if that type is a class. For example, we should use the code Item newItem = new Item(...), since the type of newItem is Item. We should not use the code var newItem = new Item(...) since the type of newItem is Item. In general, var is too vague and shouldn't be used.
• Namespace imports should be specified at the top of the file, outside of namespace declarations, and should be sorted alphabetically.