All appendices
Appendix D

The Online Coding Workflow

OnlineGDB — the default for Coding 1 & 2

Appendix D — The Online Coding Workflow

“The instrument doesn’t matter. The skill does.” — Chapter 1

For Coding 1 and Coding 2, the instrument is your browser. Coding 3 will take you off the training wheels.

Why we’re using OnlineGDB (and not a local compiler)

In these first two courses, you are going to spend your hours writing code — not installing compilers, not fixing PATH variables, not figuring out why your laptop’s antivirus quarantined g++.exe. The web has caught up; a free, zero-install C++ and Java IDE that runs in any browser is more than enough for everything we’ll do here. OnlineGDB is the default. Equivalent tools (Replit, JDoodle, Programiz) work too if you prefer one of them, with the same submission rules.

Coding 3 will introduce a local toolchain (git, a real IDE, debugger, build system) properly. For now: write code, save the project, share the link.

Setting up an OnlineGDB project

  1. Go to onlinegdb.com.
  2. Create an account. Top-right → Sign up. Email or Google login.
  3. Once logged in, you can create named projects that persist between sessions. (Without an account, you can write code but it won’t be saved.)
  4. Create your first project:
    • Hover “New File” → choose C++ (or Java for Phase 2).
    • Give it a sensible name like p1_apologist_card. The textbook will tell you the conventional name for each project.
  5. Set the compiler flags (one-time per project, important for C++):
    • Click the gear icon (⚙) → “Extra Compiler Flags” → enter: 
      -Wall -Wextra
    • These turn on the warnings the textbook expects. Code that’s “clean” in this course means clean with these flags enabled.

Project name vs. file name. These are two different things. OnlineGDB names your C++ source file main.cpp and does not offer a rename for C++ the way it does for Java. If your project lets you name the file when you create it (New File, then type the name including .cpp), use the name the assignment asks for — Project 1 wants apologist_card.cpp. If you end up with main.cpp and there is no way to rename it, leave it: no rubric line scores the file name. Do not add a second file to fix it — two files each containing main will not build.

You’ll create one project per assignment. Repeat the above for each.

Working on a project

Write your code in the editor. Press the green Run button (top of page) to compile and execute. Input the program needs (from cin or Scanner) goes into the Stdin panel below the editor — bottom panel, the tab labeled input. Next to “Standard Input:” click the Text radio button. The default is “Interactive Console,” which hides the Stdin box entirely; that one click is why most students think the panel isn’t there.

Switch back to Interactive Console whenever you want to type answers by hand and watch the program respond; switch to Text when you want a repeatable run — the warnings check, and the version you share.

Checking for warnings

“Compiles cleanly” in this course means zero errors and zero warnings under -Wall -Wextra. Here is how you actually check:

  1. Set the flags once — gear icon → Extra Compiler Flags → -Wall -Wextra. The gear is in the top toolbar, the second orange button after the language dropdown. (The gear down in the output pane is terminal settings. Wrong one.)
  2. Set Standard Input to Text, as above.
  3. Press Run. If the Stdin box is still empty, every cin reads nothing and your variables come back blank — that is expected during a warnings check. You are reading stderr here, not admiring the card.
  4. In the bottom panel, look for a tab named stderr, next to stdout. Compiler warnings land there, and the view does not jump to it on its own.

Zero errors, and nothing in stderr containing the word warning:, means you are clean. (In Interactive Console mode there is no stderr tab at all — warnings appear as yellow lines in the black console, with the source-quote lines stripped out. Text mode shows you the whole message.)

Prove your flags actually took. Add a throwaway int unused = 5; inside main, press Run, and confirm you see a warning about it. Then delete it. An empty stderr tab and a flags box that never saved look exactly the same.

Multiple files

C++ and Java projects in this course are sometimes multi-file (especially Chapters 10+ for C++, and most Java projects). OnlineGDB supports this:

  • Add a file: Right-click the project name in the file tree (left panel) → “New File” → name it (e.g., Account.java).
  • For Java, OnlineGDB compiles all .java files together; you tell it which class has main by setting the main class name in project settings.
  • For C++, you can have multiple .cpp files — OnlineGDB compiles them together when you press Run.

Saving

OnlineGDB autosaves your projects when you’re logged in. Always check the project name in the breadcrumb at the top. If it says “Untitled” you’re not saved.

Submitting your work

Every assignment in Coding 1 and Coding 2 has the same submission shape:

In OnlineGDB:

  • Log in first, and save the project with a name. Links created while logged out expire.
  • Top toolbar → Share button.
  • Choose Share a Copy, and set the expiry to Keep Forever (that option requires being logged in). “Share a Copy” freezes a snapshot: your code, your Stdin, and your compiler flags all travel with the link exactly as you left them.
  • Copy the URL it gives you — something like https://onlinegdb.com/abc123XYZ.
  • If you edit your code after sharing, share again and resubmit the new link. A snapshot does not follow your later edits.

(There is no longer any “anyone with the link can view” checkbox — a shared link is viewable by anyone who has it. Whoever opens it cannot change your code or your Stdin; they can only Run it, or fork their own copy.)

2. Leave the program in a “graded” state

The instructor will open your link and press Run. Whatever state you leave the program in is what they’ll see — and they should not have to type anything to see your work.

The rule: never delete a cin (or Scanner) read just to make the demo easier. Most Coding 1 rubrics award points for reading input, and several check your source for the read statements themselves. Replacing them with hard-coded values costs you those points even though the output looks identical.

Default — pre-fill the Stdin panel. Set Standard Input to Text (bottom panel → input tab), then type your sample answers into the box, one per line, in the order your program asks for them. That input is saved with your shared link, so the grader presses Run once and the program demonstrates itself — and your cin statements stay exactly where they are.

One word per line, unless you are using getline. cin >> stops at whitespace, so “Thomas Phillips” on line 1 means your second cin gets “Phillips” instead of the next answer.

Heads up: in Text mode your prompts print run together with nothing echoed after them, because nobody typed. That is normal, not a bug.

When hard-coding is the right move. From Chapter 8 on, projects ask main to demonstrate a class you wrote rather than to interview the user. There, hard-coded values at the top of main are exactly what the rubric wants:

int main() {
    // Seed data that exercises every operation.
    Account acct("Maya", 250.00);
    acct.give(50.00);
    acct.spend(19.99);
    acct.print_summary();
}

So: check the project’s rubric. If it pays for reading input, use the Stdin panel. If it asks main to exercise a class, hard-code the demo data.

3. Add a reflection comment

At the very top of your main source file (the one that contains main()), include a block comment like this:

/*
 * 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.
 */

This replaces the README.txt from the old submission model. Same content, different home.

4. Submit the URL

Submit the OnlineGDB link via the course portal (the instructor will tell you where — typically a discussion-board post or LMS dropbox). One URL per project.

That’s it. No demo.txt, no ZIP file, no screenshots. The instructor opens your link, reads your comment block, runs your code, and grades against the rubric.

”But what if I want to code locally?”

That’s allowed. If you have a working local C++/Java setup (you bring your own or you’ve followed Appendix A / B for setup notes), you can:

  1. Develop locally.
  2. Push your code to a public GitHub repository.
  3. Submit the GitHub repo URL in place of an OnlineGDB link.

Requirements still hold:

  • The reflection comment block at the top of the main source file.
  • The program needs to compile cleanly when checked out. The instructor will clone, compile (g++ -Wall -Wextra or javac), and run.
  • If your project needs specific inputs to demonstrate the tier, commit a sample_input.txt the grader can pipe in (./prog < sample_input.txt) and say so in your reflection block. The same rule as above applies: do not replace your cin reads with hard-coded values on a project whose rubric pays for reading input. Where main exists to exercise a class you wrote, hard-coded demo data is the right call.

You are responsible for the local setup. If your code doesn’t compile on the grader’s machine because of a missing library, missing file, or platform difference, that’s not the grader’s problem to debug — it’s yours. This is why we recommend OnlineGDB for Coding 1 and 2: there’s nothing to debug at the environment level.

Things that can go wrong (and the fix)

“The grader can’t access my OnlineGDB link.” Either you shared while logged out and the link expired, or you submitted the editor URL instead of the Share URL. Reopen the project → Share → Share a Copy → Keep Forever, and submit that URL.

“My program needs input and I didn’t leave any.” Don’t hard-code over your cin reads to fix this — you’d be deleting the thing the rubric is looking for. Pre-fill the Stdin panel instead (set Standard Input to Text first), then share again. A grader left guessing inputs is a grader who may never see the feature you built.

“My code compiles locally but not on OnlineGDB.” 99% of the time this is a missing #include. Add the include. The instructor will use OnlineGDB to grade unless your link is a GitHub repo; “works locally” is not a defense.

“I want to use Replit / JDoodle / Programiz instead.” Fine. Use any web-based IDE that produces a shareable URL where the code is visible and runnable. The submission rules are the same.

“OnlineGDB is down on the day my project is due.” Email the instructor with a screenshot of the OnlineGDB outage page. Don’t let it ruin your day.

Why no demo.txt anymore?

Earlier drafts of the course asked students to capture a terminal session and submit a demo.txt showing the program working. That made sense when projects lived in a local file system the instructor never saw. Now that every project is one click away on OnlineGDB, the instructor just runs your code themselves — the live run is the demo.

The reflection comment block (the “what I learned” paragraph) is still required. It’s the most-read part of the submission and the part where you do the most growing. Don’t skip it.

What about Coding 3?

In Coding 3 (or whichever course continues this curriculum), we’ll introduce:

  • A real local development environment (VS Code or your choice)
  • Git and GitHub workflow
  • Multi-file build systems (Makefiles, Gradle/Maven)
  • Debuggers, profilers, version control
  • Working in a team on a shared repository

For now, save those for later. The skill we’re building first is writing code. Everything else is scaffolding around that skill, and we’ll add it when the code itself is no longer the hard part.

Up next: Open Chapter 1 and start the first rep.