How this course works

Almost every idea here is explained two ways, and you choose which one you see. Textbook is the exact version, with the proper words that C# programmers and documentation use. Plain English is written for a newcomer, in everyday words, and it explains each new term the moment it shows up. Both say the same things. Plain English isn't a "lite" version. Use the switch above each explanation to flip between them. The page remembers which one you like.

Some steps depend on your computer, like how to open a terminal. Those steps come in tabs, one per option. Tell the course your setup one time, in the My setup panel on the course page. It asks two things. First, which operating system you use: Windows, macOS, or Linux. Second, which app you'll write C# in. Chapter 1 helps you choose between Visual Studio, Rider, VS Code, and just using the terminal. After that, every tabbed block opens on your choice.

Most ideas in this course are explained twice, side by side. The Textbook lane is precise: it uses the correct terms and states the rules in full, the way documentation or an interview question would. The Plain English lane says the same thing for someone meeting it for the first time, in everyday words, with each new term explained where it appears. The two lanes make the same claims; neither is a shortcut. A switch above each explanation flips between them. The choice sticks as you move through the course.

Some instructions differ by computer. Those appear as tabs. The course has two tab groups, set once under My setup on the course page or in Settings. One is your operating system: Windows, macOS, or Linux. The other is your environment, the app you'll write and run C# in: Visual Studio, Rider, VS Code, or the plain command line. Picking a tab in any lesson changes it everywhere. If a block doesn't offer your choice, it shows its first tab and leaves your setting alone.

You'll meet two kinds of question set. A check sits in the middle of a lesson and asks a few questions picked at random from a bigger pool, so coming back later gives you different ones. Checks are marked. They also help the course decide what to show you again later for review.

A practice set comes at the end of a section. It's a short ladder of 4 to 6 problems that always come in the same order. First comes one about the idea itself. Then there's an easy one, a normal one, and a twist, and last comes the one with a trap. Practice isn't marked. It's there because reading about something and doing it are different skills.

A bug hunt gives you a short program with mistakes planted in it. It tells you up front how many there are. A mistake in a program is called a bug. Sometimes you just click the broken lines. Sometimes you edit the code to repair it and press Check, and it tells you which mistakes you've fixed and whether the code is still written correctly.

A check (the questions set inside a lesson) draws a few questions at random from a larger bank, so a revisit shows a different mix. Your answers are graded and feed your progress and review schedule. A practice set is a fixed ladder of 4 to 6 problems, always in the same order. It opens with a question about the idea, then climbs through a basic case, a typical one, and a variation, and ends on the problem with the catch in it. Practice is ungraded; it exists so you can do the thing, not just read about it. Each chapter ends with review practice drawn from all its sections.

A bug hunt is a short program with planted mistakes, and it always tells you how many. It comes in two forms. In spot mode you click the line or lines that are wrong. In fix mode you edit the code in place and press Check; the checker then reports whether each planted mistake is gone and whether the code is still valid C#.

When you type code into a question on this site, the site never runs it. Your code goes to our server, and a C# parser looks at it. A parser is a program that reads code the way a grammar checker reads a sentence. It can tell whether the code is written correctly, and whether you used the piece the question asked for. It can't tell what your code would do if you ran it, just like a grammar checker can't tell whether a sentence is true. It also doesn't know whether a name you typed really exists.

So where do the outputs on the pages come from? Before a page goes live, our build runs every example program on the real C# tools, the same free kit you'll install in Chapter 1. Then it checks that the output on the page matches what really printed. If it doesn't match, the page isn't published. None of the outputs were typed in by a person.

Actually running your own code happens on your own computer. In Chapter 1 you'll run your first program with a command, dotnet run. From Chapter 3, every lab arrives with tests, small extra programs someone already wrote that check whether your program works, and a command runs them all for you. The debugger, a tool that pauses your program so you can watch it one line at a time, also runs on your computer.

Code you type on a lesson page is never compiled or run. It's sent to the course's server and checked by a C# parser: a program that reads source code and works out its structure, without translating or running it. The parser decides whether the code is valid C#, and whether it uses what the task asked for, such as a particular statement. That makes the checks fast and safe, and it sets their limits. A parser knows the shape of your code, not what the code would do when run. It can't know that a name you used doesn't exist anywhere, or what the program would print.

So anything a page shows a program doing was produced ahead of time. That covers the output under a snippet and the answer to a predict-the-output question. The course's build runs every such program on the real .NET SDK, the kit of tools (the C# compiler among them) that you install in Chapter 1, and it fails if the page doesn't match. No output on a page was typed by hand.

Running is your machine's job. From Chapter 1 you'll run small programs with dotnet run. From Chapter 3, each lab comes with tests already written, small programs that check your work, and you run them with dotnet test. Stepping through a program line by line in the debugger is also local.