Every programming language has its own writing rules: how statements are separated, how blocks of code are grouped, how things are named. Taken together, we call these rules syntax. In this lesson you'll learn the fundamental syntax rules of C# — case sensitivity, semicolons, braces, comments, naming conventions, and valid identifiers — which you'll use in absolutely every piece of code you write from now on. Mastering these rules well will save you from most of the compilation errors that tend to frustrate beginners.

1. Case sensitivity
2. Semicolons, braces, and code blocks
3. Comments: //, /* */, and ///
4. Naming conventions: PascalCase and camelCase
5. General structure of a C# file
6. Valid identifiers

C# is a case-sensitive language. This means that myVariable, MyVariable, and MYVARIABLE are considered three different names by the compiler. This affects everything: variable names, method names, class names, and even the language's own keywords.

This detail is very important because it's a common source of errors for people coming from other contexts (for example, some file systems or languages that don't distinguish uppercase from lowercase). In C#, you must always respect the exact case of every keyword and every name you use.

In C#, (almost) every statement ends with a semicolon ;. The semicolon tells the compiler "this statement ends here, the next one is independent":

Forgetting the semicolon is probably the most common syntax error when starting to program in C#. The compiler will warn you with an error message pointing to the exact line.

Braces delimit blocks of code: a set of statements treated as a single unit. We already saw in the previous lesson that a namespace, a class, and a method are each a block delimited by braces. The same will happen, later in the course, with control-flow blocks (if, loops, etc. — Module 2).

A widely spread convention (and the one we'll follow in this course) is indentation: indenting (adding spaces or tabs to) the code inside a block, so it's visually clear what belongs to what. C# doesn't require code to be indented in order to compile — unlike Python, for example — but well-indented code is far easier to read and maintain.

Don't worry yet about what if means; we'll study it in detail in Module 2. Here we're only interested in the form, not the content.

Comments are pieces of text the compiler completely ignores: they exist solely so that the people reading the code (including your future self) understand what it does or why it was written a certain way. C# offers three types:

Documentation comments (///) use a special syntax based on XML tags, such as <summary>. Although in this module we don't yet write our own methods or classes (that comes in Module 3), it's important that you recognize this syntax: many editors automatically show the content of these comments as a popup hint when you use a method, and in professional projects documenting public code this way is a highly valued practice.

A naming convention is an agreement (not a rule enforced by the compiler) about how to write the names of things in code, so it's consistent and easy to read for anyone familiar with the language. In C#, the community and the .NET team itself very consistently follow these two conventions:

Example comparing both styles using BiblioTech data:

Although the compiler doesn't force you to follow these conventions (it would compile just the same if you capitalized things differently), following them is a fundamental professional practice: it makes your code recognizable and consistent with the rest of the .NET ecosystem, including all the standard libraries (Console, WriteLine, etc., already follow PascalCase).

• Names should be descriptive: pageCount is better than n or pc.
• Underscores _ as a separator within a name are generally avoided (for example, bookTitle is preferred over book_title), although an underscore is sometimes used as a prefix in certain contexts (for example, in a class's private fields, something we'll see in Module 3).
• Accented letters or special characters aren't used in variable names, to avoid compatibility problems between keyboards, editors, and systems.

Recalling what we saw in the previous lesson, a typical .cs file (in its classic form) follows this general structure, from the outside in:

As we saw in the previous lesson, in modern projects with top-level statements, steps 2, 3, and 4 become implicit: you only write step 1 (if any extra using is needed) and step 5 directly. The compiler still generates that same structure "underneath".

You may recall that, when we looked at the generated .csproj file in the previous lesson, the <ImplicitUsings>enable</ImplicitUsings> option appeared. This option, available in modern .NET projects, makes certain very common namespaces (such as System, where Console lives) automatically available throughout the whole project, without needing to write using System; at the top of every file. That's why, in the examples from previous lessons, we've been able to use Console.WriteLine directly without any visible using line.

An identifier is the name you give to any element in your code: a variable, a method, a class, etc. C# imposes some mandatory rules (if they aren't followed, the program simply won't compile):

• It must start with a letter or an underscore _ (never with a number).
• The remaining characters can be letters, digits, or underscores.
• It can't exactly match a reserved keyword of the language (such as class, namespace, if, int...), unless written with the special @ prefix (a very uncommon technique, reserved for exceptional cases).
• It can't contain spaces or symbols like -, ., accented letters, etc.

These rules apply not only to variables but, as we'll see in later modules, to the names of methods, classes, properties, and any other element we define ourselves.

• Forgetting the semicolon: we've already mentioned this, but it bears repeating because it's by far the most frequent mistake when starting out.
• Mixing up uppercase and lowercase without noticing: writing Console.writeline(...) instead of Console.WriteLine(...) causes a compilation error, since C# is case-sensitive.
• Nesting braces without indenting: even though it compiles the same, non-indented code becomes very hard to debug as the program grows. Get your editor used to indenting automatically (most do it when you press Enter).
• Using non-descriptive names: variables like x, a1, temp make the code harder to understand later on. Always prefer descriptive names like bookTitle or isAvailable.
• Confusing convention with obligation: PascalCase and camelCase are conventions, not compiler rules; but following them is what's expected of any professional C# code, and we'll follow them throughout the course.
• Tip: when the compiler points out a syntax error on a line, also check the line before it: often the real error (like a missing semicolon) is right before where the problem is reported.

1. From the following list of identifiers, indicate which are valid in C# and, for the ones that aren't, explain why: pageCount, 3isbn, _title, full name, namespace, Author2.

2. Rewrite the following code fragment, correctly applying naming conventions (camelCase for variables) and proper indentation:

   string TITLE = "Don Quixote";
   int Pages=863;
   bool Available=true;
   Console.WriteLine(TITLE);
   

3. Add to your corrected fragment from the previous exercise: a single-line comment explaining what the pages variable is for, and a block comment (/* */) at the top of the file briefly explaining what the whole program does.

1. • pageCount → Valid (starts with a letter).
   • 3isbn → Not valid (starts with a digit).
   • _title → Valid (starts with an underscore).
   • full name → Not valid (contains a space).
   • namespace → Not valid (it's a reserved keyword of the language).
   • Author2 → Valid (starts with a letter, contains a digit that isn't the first character).

2. Corrected version:

   string title = "Don Quixote";
   int pages = 863;
   bool available = true;
   Console.WriteLine(title);
   

   TITLE, Pages, and Available (capitalized, as in PascalCase) were changed to title, pages, and available in camelCase, appropriate for local variables; a space was also added around the = sign for readability, although the compiler would accept both forms.

3. Sample solution:

   /*
      BiblioTech sample program.
      Displays the title of a book from the catalog.
   */
   string title = "Don Quixote";
   int pages = 863; // Total number of pages in the book
   bool available = true;
   Console.WriteLine(title);
   

In this lesson you learned the syntax rules that govern any C# program: the distinction between uppercase and lowercase, the use of semicolons and braces to delimit statements and blocks, the different types of comments, the PascalCase and camelCase naming conventions, the general structure of a file, and the rules for a valid identifier. With this foundation you can now read and write syntactically correct, well-organized C# code.

In the next lesson, Variables and Data Types, we'll put these naming rules into practice by declaring actual variables with different data types — numbers, text, boolean values — using as an example the data of a BiblioTech book: its title, its ISBN, its page count, and whether it's available or not.