HAP learning about code grammar

Station 2: The Grammar of Code

Statements, semicolons, and comments

Welcome to Station 2! I wrote some code and it just... stopped. No error message, no output, nothing. I stared at the screen for ten minutes.

The code looked right. But something invisible was wrong.

Prof. Teeters glanced over. "Read it like a sentence," she said. "Where does one thought end and the next begin?"

That's when I realized: code has grammar, just like English. Sentences need periods. Statements need semicolons.

Let me show you the grammar rules that saved my sanity... 🟠

What You'll Learn at This Station

HAP's Discovery: Code has grammar rules, just like English! Statements are like sentencesβ€”each one is an instruction. Semicolons are like periodsβ€”they mark where one statement ends. And comments are like margin notesβ€”they help you (and others) understand what the code does. Here are the three key insights:

πŸ“ Statements

Instructions

Each statement tells JavaScript to do one thing. Like sentences in English, they're the building blocks of your program.

; Semicolons

End markers

Semicolons mark where statements end. Like periods in sentences. Always use themβ€”don't let JavaScript guess!

πŸ’¬ Comments

Notes to self

Comments explain your code to humans. JavaScript ignores them completely. Future-you will thank present-you!

HAP surrounded by tangled code with an 'oops' expression

HAP's Confession:

  • I forgot a semicolon and JavaScript guessed where my statement ended. It guessed wrong. My code broke in a way that made no sense until I understood ASI.
  • I wrote code with no comments. Three days later, I had no idea what it did. Now I comment as I write!
  • I thought comments were optional extras. Prof. Teeters said they're "a gift to future-you." She was right.

Statements β€” Instructions for JavaScript

A statement is a single instruction that tells JavaScript to do something. Your program is a list of statements that run one after another, top to bottom.

Statements in action:
// Each line is a STATEMENT - an instruction for JavaScript to follow
const robotName = "HyBit A. ProtoBot";
let energyLevel = 100;
console.log(robotName);
energyLevel = energyLevel - 15;

// Statements are like sentences in English
// Each one tells JavaScript to DO something

Each line is one statement. JavaScript reads them in order: first it creates robotName, then energyLevel, then it logs, then it subtracts.

Declaration Statements

const robotName = "HAP"; creates a new variable and gives it a value.

Assignment Statements

energyLevel = 85; changes an existing variable's value.

Function Call Statements

console.log("Hello"); runs a function to do something.

Top to Bottom

JavaScript runs statements in order. Line 1 happens before line 2.

Semicolons β€” The Periods of Code

In English, periods mark where sentences end. In JavaScript, semicolons mark where statements end. Without them, things get confusing:

Semicolons mark statement endings:
// Semicolons mark the END of a statement
const robotName = "HyBit A. ProtoBot";  // Statement 1
let energyLevel = 100;                   // Statement 2
console.log(robotName);                  // Statement 3

// Think of semicolons like periods in English:
// "My name is HAP. I am a robot. I love learning."
// Without periods, it's confusing. Same with code!

Every statement ends with a semicolon. It's clear, it's explicit, and it prevents weird bugs.

🟠 HAP's Tip:

Treat semicolons like periods in sentences. Every statement gets one. const name = "HAP"; is like saying "My name is HAP." The semicolon says "This thought is complete."

Why Explicit Semicolons Matter

JavaScript has a feature called "Automatic Semicolon Insertion" (ASI). It tries to guess where semicolons should go. But sometimes it guesses wrong:

When JavaScript guesses wrong:
// JavaScript can GUESS where statements end (Automatic Semicolon Insertion)
// But sometimes it guesses WRONG!

// This looks like it should work...
const greeting = "Hello"
const name = "HAP"

// But this causes a problem:
return
    "Hello, HAP!"

// JavaScript thinks you meant:
return;  // Returns undefined!
"Hello, HAP!";  // This line never runs

// The fix: Always use explicit semicolons!
return "Hello, HAP!";

ASI inserted a semicolon after return, breaking the code. This is why explicit semicolons are safer!

Grace Hopper Interjects:

"The specification does allow omitting semicolons. However, relying on the interpreter to infer your intent is imprecise. State your intent explicitly. Ambiguity is the enemy of correctness."

HAP having a breakthrough moment

Breakthrough Moment!

Grace was right. I added semicolons everywhere. Now I treat them like periods in sentences. Every statement gets one. No guessing, no surprises!

Single-Line Comments

Comments are notes that JavaScript completely ignores. They're for humansβ€”especially future-you! Single-line comments start with //:

Using // for comments:
// This is a single-line comment
// JavaScript ignores everything after //

const robotName = "HyBit A. ProtoBot";  // This explains the line
let energyLevel = 100;  // Starting energy

// Comments are notes to yourself (and others)
// They don't affect how the code runs

Everything after // on that line is ignored. Use these for quick notes and explanations.

Multi-Line Comments

For longer explanations, use multi-line comments. They start with /* and end with */:

Using /* */ for longer comments:
/* This is a multi-line comment.
   It can span multiple lines.
   Great for longer explanations! */

const robotName = "HyBit A. ProtoBot";

/*
   Robot ID Card Configuration
   ---------------------------
   These values define HAP's identity.
   robotName: The full official name
   modelNumber: The hardware designation
   creationYear: When HAP was built
*/
const modelNumber = "HAP-7000";
const creationYear = 2024;

Everything between /* and */ is ignored. Great for documentation blocks and temporarily disabling code.

// Single-line

Quick notes. One line only. Good for explaining a specific line of code.

/* Multi-line */

Longer explanations. Can span many lines. Good for documentation blocks.

Explain the "Why"

Good comments explain why code exists, not just what it does.

Don't Over-Comment

// Add 1 to x before x = x + 1 is unnecessary. The code is already clear.

Well-Commented Code

Here's what good commenting looks like in practiceβ€”clear sections, meaningful explanations, and organized structure:

A well-commented code example:
// ═══════════════════════════════════════════════════════════
// HAP's Robot ID Card - Variable Declarations
// ═══════════════════════════════════════════════════════════

// Facts about HAP (these never change)
const robotName = "HyBit A. ProtoBot";
const modelNumber = "HAP-7000";
const creationYear = 2024;

// HAP's current state (these change as HAP works)
let energyLevel = 100;       // Percentage, decreases with tasks
let tasksDone = 0;           // Count, increases as tasks complete
let statusMessage = "Ready to learn!";  // Updates after actions

// Display the initial state
console.log("Robot initialized:", robotName);
console.log("Energy:", energyLevel + "%");

Section headers, inline explanations, and clear organization. Future-you will understand this code at a glance!

🟠 HAP's Comment Philosophy:

I comment to help future-me understand present-me's thinking. Not every line needs a comment, but every confusing bit does. If I had to think hard to write it, it needs a comment explaining why!

πŸŽ“ Code Grammar Quick Reference

1

Statements are instructions

Each statement tells JavaScript to do one thing. Programs are lists of statements.

2

End statements with semicolons

const x = 5; β€” The semicolon says "this statement is complete."

3

Don't rely on ASI

JavaScript can guess where semicolons go, but it sometimes guesses wrong. Be explicit!

4

// for single-line comments

Everything after // on that line is ignored by JavaScript.

5

/* */ for multi-line comments

Everything between /* and */ is ignored. Can span many lines.

6

Comments are gifts to future-you

Explain the "why," not just the "what." You'll thank yourself later!