Resource Names

Problem
You want to know the recommended naming convention for resources.

Solution
Use PascalCase for resource names. In general, you’ll want to follow the same guidelines you use when naming public fields.
1. Use descriptive names.
2. Don’t include spaces or punctuation marks.
3. Don’t start the name with a digit.
4. Avoid keyword names like long.

Comments
For example, ChromeDriver is a good resource name, whereas chromeDriver and Chrome:Driver aren’t. In addition, feel free to include dots to specify the property of an object (e.g. lblSearch.Text) or to separate elements in a hierarchy, such as Menus.Edit.Reformat.Text.

Commenting out Code in C#

Problem
You want to know the best way to comment out blocks of code.

Solution
Use single-line comments instead of block comments to comment out blocks of code. Be sure to place the // symbol in the first column. This helps make it clear that it isn’t a standard comment.

Comments
Avoid commenting out executable lines of code; especially, before checking it in. Lines of code that are commented out and ignored tend to become dead code.

Comment Position and Indentation

Problem
You want to know where to place comments and how they should be indented.

Solution
Comments should use the same indenting level as the code block it’s related to and immediately before it. There should be no blank lines in between.

Examples

// This is wrong. It's not indented and a blank line is used.
for ( int i = 0; i <= arr.Length; i++ )
{    
// Initialize the array element.

    arr[i] = i;
}

// This is correct.
for ( int i = 0; i <= arr.Length; i++ )
{
    // Initialize the array element.
    arr[i] = i;
}

Guidelines for Curly Braces in C#

Problem
You want to know where to place curly braces when defining a block of C# code.

Solution
Open and close curly braces on a line of their own.

Comments
Some folks like to use the C convention of placing open curly braces on the same line as the statement that defines the block. This style is fine as long as everyone working on the code consistently applies it. It’s a matter of preference that’s typically a choice between code readability and conciseness. I choose readability.

Example

// This style enhances readability.
void DoSomething(int x)
{
    if ( x == 0 )
    {
        ...
    }
    else
    {
        ...
    }
}

Wrapping Lines in C#

Problem
You want to know when to wrap long lines of C# code.

Solution
Use the following guidelines to help you decide where to insert a new line to split a long statement.

• Break a long line after a comma but before an operator. Beginning a new line with an operator makes it clear that it’s the result of statement splitting.
• Avoid wrapping a line in the middle of an expression, especially if in the middle of a parenthesized expression.
• Try to keep all items at a given nesting level on the same line.
• Don’t create excessively long lines if you later need to split them. Consider using temp variables to reduce expression complexity.
• Indent all wrapped lines by one tab.

Examples

// This is incorrect. A parenthesized expression is split, leaving an operator on the first line.
result = DoWork(first, second * (third +
    fourth));

// Both of these are correct, but the second one is better.
result = DoWork(first, second
    * (third + fourth));
result = DoWork(first,
    second * (third + fourth));