Introduction
A sketch is written for two readers. The compiler has to turn it into something the chip can run, and it is completely unforgiving. The next person has to understand it six months later, and that person is usually you.
Syntax is the set of rules that keeps the first reader happy. There are only a handful of them, and almost every error a beginner meets is one of these five things being missing or unmatched:
- a semicolon
;at the end of a statement - a matching pair of curly braces
{ } - a comment that was never closed
- a
#definewritten like a variable - a missing
#includefor a library you used
None of them are difficult. They are just strict. Learn to read the error message and you stop losing twenty minutes to a missing character.
The second reader is what comments are for. A sketch that works but that nobody can follow is only half finished.
What you will be able to do
By the end of this lesson you can:
- End a statement correctly, and spot a missing semicolon from the error message.
- Match every
{with its}, and use auto-format to check. - Write both kinds of comment, and use one to disable code temporarily.
- Define a constant with
#define, and say whyconst intis usually better. - Bring in a library with
#include, and tell<brackets>from"quotes". - Read the four commonest compiler errors and know what each one means.
What you need
| Part | Type | Qty |
|---|---|---|
| Arduino UNO R3 | Microcontroller | 1 |
| USB A to B cable | Cable | 1 |
Basic
No wiring in this lesson. Every example uses LED_BUILTIN, the small LED already on the board.
→ Anatomy of a Sketch — where setup() and loop() come from, and what runs when.
1. The semicolon
A semicolon ends a statement — one complete instruction.
digitalWrite(LED_BUILTIN, HIGH);
delay(1000);Leave one out and the compiler complains about the next line, because it is still waiting for the first one to finish:
error: expected ';' before 'delay'
Read that as "the line above me". The error points at where the compiler gave up, not at where you went wrong.
Not everything takes one. if, for, while and function definitions are followed by a block, not a semicolon:
if (x > 5) { // no semicolon here
...
}Putting one after if (x > 5); is legal C++ and means "if this is true, do nothing". It compiles cleanly and the block always runs. That one costs people hours.
2. Curly braces
Braces group statements into a block. Everything between { and } belongs together.
void setup() {
pinMode(LED_BUILTIN, OUTPUT);
}Every { needs exactly one }. Miss one and you get:
error: expected '}' at end of input
Press Ctrl+T (Cmd+T on a Mac) in the Arduino IDE. It re-indents the whole sketch. If a block suddenly slides far to the right, that is where the missing brace is — far quicker than counting.
3. Comments
Two kinds. Neither is compiled; both are for people.
Challenges
Challenge 1
Find the three mistakes.
This sketch does not compile. There are exactly three errors.
#define LED_PIN = 13;
void setup() {
pinMode(LED_PIN, OUTPUT)
}
void loop() {
digitalWrite(LED_PIN, HIGH);
delay(500);
digitalWrite(LED_PIN, LOW);
delay(500);
}Type it in, press Verify, and fix them one at a time. Write down each error message before you fix it, and which line it was really about.
Log in to ask for the answer.
Challenge 2
Switch code off without deleting it.
Start from the working blink sketch.
- Using comments only, make the LED stay on for ever.
- Change nothing but comments again, and make it stay off for ever.
- Put it back to blinking.
You may not delete or retype a single line — only add and remove //.
Then do step 1 again using a /* */ block instead.
Log in to ask for the answer.
Challenge 3
Two ways to name a pin.
Take the blink sketch and give pin 13 a name twice over:
- First with
#define LED_PIN 13. - Then delete it and use
const int LED_PIN = 13;instead.
Both work. Now break each one on purpose:
- Add a semicolon to the end of the
#defineline and press Verify. Read the error. - Write
const int LED_PIN 13;with no equals sign. Read that error too.
Extra challenge
A sketch somebody else could read.
Write a blink sketch that a classmate could pick up cold. It must have:
- a block comment at the top with the title, your name, the date and one line saying what it does
- a
#defineorconst intfor the pin, named for what it is, not what number it is - a
//comment abovesetup()and aboveloop()saying what each part does - a section you have deliberately switched off with comments, and a note saying why
Then hand it to the person next to you. They must be able to say what it does without you speaking. If they cannot, the comments are not finished.
Think about it: the compiler ignores every one of those comments. The sketch is exactly the same size and runs exactly as fast. So who did you write them for?
Log in to ask for the answer.