Syntax and Comments

C# has a small set of rules for how code is written: statements end with semicolons, blocks are wrapped in braces, names are case-sensitive, and comments let you leave notes for human readers. Knowing these rules — and the naming conventions every C# developer follows — makes code easier to read and errors easier to fix.

Statements and blocks

A statement is one instruction, ending with ;. A block groups statements inside { }, for example the body of an if or a loop:

int hour = 14;

if (hour < 12)
{
    Console.WriteLine("Good morning");
    Console.WriteLine("Coffee time.");
}
else
{
    Console.WriteLine("Good afternoon");
}

Good afternoon

The C# convention (called Allman style) puts each opening brace on its own line. The compiler doesn't care about line breaks, spaces or indentation — this would compile too — but nobody wants to read it:

int hour = 14; if (hour < 12) { Console.WriteLine("Good morning"); } else { Console.WriteLine("Good afternoon"); }

Good afternoon

Most editors format C# for you: in VS Code use Format Document, or run dotnet format on a project.

Case sensitivity

C# treats upper- and lower-case letters as different. total, Total and TOTAL are three separate names, and keywords like if must be lower-case.

int count = 1;
int Count = 2;
Console.WriteLine(count + Count);

3

That compiles, but using names that differ only by case is confusing. Don't do it in real code.

Identifiers and naming conventions

Names you choose (for variables, methods, classes …) are identifiers. They may contain letters, digits and underscores, but can't start with a digit or be a keyword like class or int. C# code follows consistent naming conventions:

Pick descriptive names: secondsElapsed says far more than s or tmp.

If you really need a keyword as a name — for example when matching data from another system — prefix it with @:

string @class = "Physics 101";
Console.WriteLine(@class);

Physics 101

Comments

Comments are ignored by the compiler. Use them to explain why code does something that isn't obvious.

// A single-line comment runs to the end of the line.
int seats = 120;  // comments can follow code too

/* A multi-line comment
   can span several lines. */
int booked = 87;

Console.WriteLine(seats - booked);  // free seats

33

Comments are also handy for temporarily disabling a line while you test something — most editors toggle this with Ctrl+/ (Cmd+/ on macOS).

Documentation comments

A comment starting with /// above a method or type is a documentation comment. It uses XML tags, and editors show it as a tooltip wherever the method is used:

Console.WriteLine(Celsius(98.6));

/// <summary>Converts a temperature from Fahrenheit to Celsius.</summary>
/// <param name="fahrenheit">The temperature in degrees Fahrenheit.</param>
/// <returns>The temperature in degrees Celsius.</returns>
static double Celsius(double fahrenheit) => (fahrenheit - 32) * 5 / 9;

37

You'll write methods like Celsius from lesson 20. Documentation comments matter most on public code that other people will call.

using directives

Types in .NET are grouped into namespaces. To use a type by its short name, its namespace must be imported with a using directive at the top of the file. Common namespaces are imported for you automatically (lesson 4), but others need a line like this:

using System.Text;

var sb = new StringBuilder();
sb.Append("Built ");
sb.Append("piece by piece");
Console.WriteLine(sb.ToString());

Built piece by piece

Without the using line you'd have to write the full name, System.Text.StringBuilder. Lesson 59 covers namespaces in depth.

Try it yourself

Add comments explaining each step, then rename the variables to follow the camelCase convention.

Area: 40