Appendix A — The Online Coding Workflow

“The tool is not the sport. The reps are the sport.”

Everything this course requires runs in a browser tab and costs nothing.

This is the only setup in Accelerated Coding 1. There is no second appendix that installs a compiler on your laptop, because you do not need one. Every rep, every project, and both halves of both exams run in a free browser IDE, on any machine that can open a web page.

Budget fifteen minutes, before Week 1 — not on the night Project 1 is due.

Coach’s Note — OnlineGDB rearranges its buttons from time to time. If a label named below has moved, the thing still exists — look along the toolbar and inside the gear menu.

Why a Browser IDE

You are here to write code, not to fight a PATH variable. The classic beginner’s first week goes to an install that half-works: an antivirus quarantines the compiler, the terminal insists g++ is not a command. None of that teaches you programming. It just eats the twelve hours you set aside.

OnlineGDB — https://www.onlinegdb.com/ — is a free, zero-install C++ and Java IDE that runs in the browser. Free means free: no license, no institutional login, no trial that expires in Week 5. It is the default here, and three other free web IDEs (Replit, https://replit.com/; JDoodle, https://www.jdoodle.com/; Programiz, https://www.programiz.com/) are acceptable substitutes under identical submission rules.

The second reason matters more when nobody is in the room: the grader runs the same environment you do. OnlineGDB compiles with GNU g++ on Linux — which is why the compiler messages decoded in every chapter’s Common Bugs section match your screen, and why the Week 6 memory-leak check works there and silently does nothing on a Mac. “It worked on my machine” cannot come up when your machine is the grader’s.

Step 1 — Make the Free Account

Open https://www.onlinegdb.com/ and sign up (top right). Email or a Google login; both are free.

You can type and run code without an account. You cannot keep it — close the tab and the work is gone, not recoverable, not in a drafts folder. Two things here need the account: named projects that survive between sessions, and the share link that is your submission. Unsaved work is lost work, and a retyped evening costs a quarter of a week in a course with only eight.

Step 2 — Create a C++ Project, and Name It Properly

Logged in, create a project rather than typing into the scratch editor: a project has a name, a file list, its own compiler settings, and it persists. Choose C++ in the language selector.

This course names projects p<number>_<short_slug> — lowercase, underscores, no spaces:

Each project brief also names the main source file it expects — the one containing main — and that name wins over anything here.

One project per graded item, eight by the end of the term. They cost nothing, and in Week 5 you will want to reopen Week 2.

Step 3 — Turn On -Wall -Wextra Before You Type a Line

Not optional. Every project in this book is graded on compiling cleanly, and “cleanly” means with these two flags on and zero warnings. A project that is silent without them and throws four warnings with them has not met the bar.

Where the setting lives: click the gear icon in the editor toolbar, find the Extra Compiler Flags box, and type:

-Wall -Wextra

Apply it. The setting belongs to the project, so set it the moment you create one.

Why it earns its own step — here is a program with a real bug in it:

#include <iostream>
using namespace std;

int main() {
    int total;
    for (int i = 1; i <= 3; i++) {
        total += i;
    }
    cout << "Total: " << total << endl;
    return 0;
}

total is never initialized, so total += i adds to whatever junk was in that memory. With no flags the compiler says nothing at all — it builds, it runs, and it prints a number that may even look right on the day you test it. With -Wall -Wextra it names the line, names the variable, and tells you it is being used uninitialized.

Warnings are not nagging. They are the compiler naming a bug it can already see and you cannot.

Coach’s Note — In Week 6 you add one more flag to the same box, space-separated: -Wall -Wextra -fsanitize=address. That is the memory-leak detector Chapter 6 grades you against.

Step 4 — Run It, and Learn Where Things Land

The green Run button compiles and, if compilation succeeds, runs — the whole compile-then-run loop in one click. Two things land in the editor’s console area:

• Compiler messages — errors and warnings, printed before your program starts. With errors, the program never runs and the console holds only diagnostics.
• Program output — everything your cout or System.out.println produced, once compilation succeeded.

If a run produced no output, look up: the answer is almost always an error above where you were looking. Read the first error, not the last — one missing semicolon can generate nine complaints, eight of them the compiler flailing after the first confused it.

While a program runs, the Run control becomes a Stop control. Infinite loop flooding the console? Click Stop; if the page is too busy to respond, reload the tab. The runner dies with it, undamaged.

Step 5 — The Stdin Box

A program that reads input needs somewhere for that input to come from. OnlineGDB gives you two ways.

Interactive — you type answers into the console while the program runs, the way a terminal works.

Pre-filled Stdin — you paste the input into a Stdin box before pressing Run and the program consumes it automatically. Look for the console area’s interactive-console toggle; switch interactive mode off and the Stdin box appears. Take this program:

#include <iostream>
#include <string>
using namespace std;

int main() {
    string name;
    int weeks = 0;

    cout << "Your name: ";
    getline(cin, name);
    cout << "Weeks into the course: ";
    cin >> weeks;

    cout << name << " has " << (8 - weeks) << " weeks to go." << endl;
    return 0;
}

Put these two lines in the Stdin box:

Maya Ellison
1

Press Run, and the console shows exactly this:

Your name: Weeks into the course: Maya Ellison has 7 weeks to go.

The prompts run together because pre-filled input is not echoed — nothing was typed, so nothing appears between them. That is normal, not a bug; typed interactively, your answers show after each prompt.

One input per line, in the order the program reads them. An empty Stdin box means end-of-file at once: getline gives you an empty string, and in C++11 and later a failed cin >> weeks sets weeks to 0.

Why this matters for grading: a program waiting on input nobody knew to supply looks, from the other side of the link, exactly like a program that hangs. Pre-filled Stdin is one of the two approved ways to hand in a program that runs itself.

Java, from Week 7 On

Same account, same projects, same Run button — create a project and choose Java in the language selector. No JDK, no second account.

import java.util.Scanner;

public class Main {
    public static void main(String[] args) {
        Scanner in = new Scanner(System.in);
        System.out.print("Your name: ");
        String name = in.nextLine();
        System.out.println("Ready to work, " + name + ".");
    }
}

With Maya Ellison in the Stdin box, that prints:

Your name: Ready to work, Maya Ellison.

Two Java rules. The filename must exactly match the public class, capitalization included — public class Main lives in Main.java, and renaming one without the other is the first error most students meet in Week 7. And -Wall -Wextra are C++ flags meaning nothing to javac; if a flags box appears for a Java project, leave it empty.

More Than One File

This course submits one file, deliberately, all eight weeks:

• C++ — one .cpp, always, including from Week 5 when your programs carry several classes. Several classes in one file is ordinary C++ and it is the shape you hand in.
• Java — one file, exactly one public class matching the filename, any number of non-public helper classes below it. Chapter 7 shows the pattern.

OnlineGDB does multi-file projects anyway, and it is worth knowing how — real code is multi-file, and you may want it on the GitHub path below.

• Add a file through the project’s file list in the left panel; the new-file control names it (Account.java, report.cpp).
• C++ compiles every .cpp together on Run. Exactly one may define main; two is a link error, not a compile error, so read that message carefully.
• Java compiles every .java together and then has to decide which class to start. Set the main class in the project’s settings to the class holding public static void main(String[] args). Skip that and the project may refuse to run or start the wrong class — confusing, because nothing is wrong with your code.

Multi-file is what real projects look like; single-file makes your share link one click. Here, single-file wins.

Saving, and How to Know You Actually Saved

OnlineGDB autosaves projects while you are logged in. Trust that for small edits; do not trust it with three hours of work.

How to tell: look at the project name at the top of the editor. A real name means a real, saved project; Untitled means a scratch buffer, one closed tab from losing all of it — press Save and name it now. At the end of every session, press Save, reload the page, confirm your code came back. Ten seconds, and “I lost everything” never happens to you.

Submitting

Every graded item — six projects and both Part B practicals — is submitted the same way: one URL. No ZIP file, no screenshots, no demo.txt. Whoever grades you opens the link, reads your comment block, presses Run, and grades against the rubric.

1. Get the share link

Press Share in the toolbar. A dialog gives you a URL of the form https://onlinegdb.com/XXXXXXXX. Set visibility so that anyone with the link can view, then copy the URL.

Make sharing the last thing you do: edit, save, Share, copy. Never assume a link generated Tuesday reflects code you fixed Thursday — re-share after your final edit and you never have to find out which way it works.

2. Verify the link before you submit it

Open a private or incognito window, paste the URL, load it. If it asks you to log in, shows nothing, or 404s, it is not shareable. Twenty seconds — and skipping it is the most common way a finished project arrives as a blank submission. A link only you can open is no submission at all.

3. Leave the program in a state that demonstrates itself

The grader presses Run once, and whatever happens on that run is your project. Two approved ways: hard-code the inputs at the top of main, so the run demonstrates itself with nothing typed; or pre-fill the Stdin box and save, so your sample input travels with the project. Either is fine; hard-coding is more beginner-proof, with no panel state to forget.

4. The reflection comment block — required, every time

At the very top of your main source file — the one containing main — put exactly this block, filled in. Unchanged, it works in C++ and Java:

/*
 * Tier targeted:    Normal / Medium / Hard
 * Features done:    list the ones you finished
 * What I learned:   one short paragraph; no bullets
 * What I'd change:  one sentence
 * AI usage:         where and how, if any. Be honest.
 */

It is graded, it is short, and it is the one place where you make your own case. Be specific on AI usage: the rule here is that code you cannot explain is treated as code you did not write, and an honest line costs you nothing.

5. Submit the URL in Canvas

One URL in the assignment box. Then close the laptop.

The sixty-second pre-flight

1. Extra Compiler Flags reads -Wall -Wextra; the last Run gave zero warnings.
2. The reflection block is at the top of the main file, filled in.
3. Inputs are hard-coded, or the Stdin box holds them and is saved.
4. The project has a real name, not Untitled.
5. Share link generated after the last edit, set to anyone-with-the-link.
6. Link opened in a private window.

The GitHub Path (Optional)

If you already have a working local compiler, develop locally and submit a public GitHub repository URL (https://github.com/) in place of an OnlineGDB link. Nothing else changes: the reflection block still sits at the top of the main source file, the program still has to demonstrate itself (hard-coded values or a sample_input.txt in the repo), and it still has to compile cleanly under g++ -std=c++17 -Wall -Wextra or javac.

The burden is entirely yours. If it does not compile on the grader’s machine — a missing file, a missing #include, an uncommitted change, a platform difference — that is your bug to find, and nobody is available to debug your environment with you. A private repository is an unopenable link and scores like an empty one. One trap in particular: the Week 6 leak check does nothing at all on a Mac, silently, so run that check in OnlineGDB regardless. If that sounds like friction, it is the point of the default.

When Something Goes Wrong

“The grader can’t open my link.” Visibility was never set to anyone-with-the-link, or you shared before your last save. Reopen, save, Share again, set visibility, test the new URL privately.

“My program needs input and I forgot to provide it.” From the outside it looks hung. Hard-code the values at the top of main, or paste them into the Stdin box and save. Nobody can guess which three numbers demonstrate your Hard tier.

“It compiles locally but not on OnlineGDB.” Almost always a missing #include — local compilers pull extra headers in behind your back; GNU g++ on Linux does not. Add the include the error names. Unless you submitted a GitHub repo you are graded in OnlineGDB, so “works locally” is not a defense — it describes a bug you have not found yet.

“I’d rather use Replit / JDoodle / Programiz.” Allowed. Any free web IDE producing a shareable URL where the code is visible and runnable is fine, under every rule above.

“OnlineGDB is down and my work is due today.” Do not spend the evening refreshing. Open one of the other three free IDEs, paste your code in, share from there, submit that link, and email the instructor one line naming the tool, with a screenshot of the outage. A detour, not a lost project.

“I closed the tab and my code is gone.” Logged in with a named project, it is in your projects list. If it said Untitled, nothing brings it back — Step 1 collecting its debt.

What a Submission Looks Like, End to End

Do this once now, so the first time you run the loop is not the night Project 1 is due. This is not Project 1 — it is a two-minute stand-in.

1. Create a C++ project named appendix_a_dry_run.
2. Gear icon → Extra Compiler Flags → -Wall -Wextra.
3. Type this in (type it, don’t paste it — the reps start now):

/*
 * Tier targeted:    Normal
 * Features done:    prints a labeled card; computes weeks remaining
 * What I learned:   one short paragraph; no bullets
 * What I'd change:  one sentence
 * AI usage:         where and how, if any. Be honest.
 */

#include <iostream>
#include <string>
using namespace std;

int main() {
    // Hard-coded so the grader can press Run and see the whole thing.
    string name = "Maya Ellison";
    int weeks_done = 1;

    cout << "===== Apologist's Card =====" << endl;
    cout << "Name:      " << name << endl;
    cout << "Weeks in:  " << weeks_done << " of 8" << endl;
    cout << "Remaining: " << (8 - weeks_done) << endl;

    return 0;
}

4. Press Run. Zero warnings, and exactly this output:

===== Apologist's Card =====
Name:      Maya Ellison
Weeks in:  1 of 8
Remaining: 7

5. Save. Confirm the project name at the top is appendix_a_dry_run, not Untitled.
6. Share → set anyone-with-the-link → copy the URL.
7. Open a private window, paste the URL, and watch your card come up on a browser that has never heard of you.

That is the entire submission workflow. Six more times for the projects, twice for the practicals, and the mechanics of this course are behind you.

Up next: Read Appendix B — twelve hours a week alone is a skill of its own, cheaper to learn now than in Week 3. Then open Chapter 1 and type your first program.