Tooling

A real project might have Contact.cpp, ContactBook.cpp, and main.cpp, each depending on the others. Manually typing out every file and every compiler flag by hand, every single time, is genuinely tedious and error-prone — especially across different machines with different compilers or library locations.

cmake_minimum_required(VERSION 3.10)
project(ContactBook)

set(CMAKE_CXX_STANDARD 17)

add_executable(contactbook main.cpp Contact.cpp ContactBook.cpp)

CMake reads this configuration file and GENERATES the actual build instructions for your specific platform — you describe WHAT you want built, and CMake figures out HOW, on whatever machine it's run on. add_executable lists every source file that goes into the final program.

mkdir build
cd build
cmake ..
cmake --build .

This directly builds on the Pre-Course's terminal navigation (mkdir, cd). Building in a separate build folder — rather than mixing generated files with your actual source code — is standard, genuinely widespread practice.

A breakpoint marks a specific line where execution should pause — most IDEs (including this platform's CLion GUI Development course) let you set one by clicking in the margin next to a line number. When the program reaches that line, it freezes, letting you inspect exactly what's happening at that precise moment.

The Pre-Course's Module 13 print-statement trick is genuinely useful for quick checks, but it requires you to guess in advance what to print, and requires editing (then removing) code just to look. A debugger lets you inspect ANYTHING, at ANY paused moment, without changing a single line of your actual source code — genuinely faster once you're comfortable with it, especially for a bug whose exact cause isn't obvious yet.

Git takes a snapshot of your entire project every time you make a commit — a saved checkpoint you can always return to. This isn't about "saving the file" the way you already do in your editor — it's a genuinely complete history of every meaningful change, with the ability to see exactly what changed, when, and why.

git init                          # start tracking a project
git add main.cpp                  # stage a specific file's changes
git commit -m "Add contact search"  # save a checkpoint, with a message
git log                           # view the full history of commits

git add stages WHICH changes you want included in the next checkpoint; git commit actually saves that checkpoint, with a message describing what changed and why — genuinely similar in spirit to Module 1's #Setting Up a Real Project habit from Phase 1, just tracking every version instead of only the current one.

git branch new-feature      # create a new, separate line of development
git checkout new-feature    # switch to working on it

A branch lets you experiment or build a new feature genuinely separately from your main, working code — if the experiment doesn't work out, you can abandon it entirely without ever having risked the working version.

The Pre-Course's Module 13 covered ERRORS — mistakes that stop compilation entirely. A warning is different: the code IS technically valid and WILL compile, but the compiler has noticed something that's very likely a real mistake anyway — an unused variable, a suspicious comparison, a possible uninitialized value.

g++ -Wall -Wextra main.cpp -o program

-Wall ("all warnings," though genuinely not literally every possible one) and -Wextra enable significantly more warning categories than the compiler's bare default — catching real, genuine issues like Phase 1 Module 6's forgotten-variable-initialization trap, or an unused function parameter, well before they become confusing runtime bugs.

Static analysis examines your source code WITHOUT ever actually running it — genuinely different from Module 2's debugger, which inspects a program while it's actively executing. A static analyzer traces through possible code paths mathematically, looking for patterns that are almost always real bugs.

void testGetMax() {
    if (getMax(5, 3) != 5) {
        std::cout << "FAIL: getMax(5, 3) should be 5" << std::endl;
    } else {
        std::cout << "PASS: getMax(5, 3)" << std::endl;
    }
}

A unit test is genuinely just this — code that calls another piece of code and CHECKS whether the result matches what you expect, automatically. This is Phase 9's getMax template, now genuinely verified by code instead of by you manually reading printed output and judging it yourself.

TEST_CASE("getMax works correctly") {
    REQUIRE(getMax(5, 3) == 5);
    REQUIRE(getMax(1, 10) == 10);
}

A real testing framework like Catch2 (or Google Test) handles all the pass/fail reporting, running hundreds of tests automatically, and giving a clear summary — you focus purely on writing the actual checks (REQUIRE), not the reporting machinery around them.

Real, professional codebases have hundreds or thousands of tests, run automatically every time code changes — catching a bug the MOMENT it's introduced, not weeks later when a user reports it. Writing testable code (small, focused functions with clear inputs/outputs — genuinely everything Phase 3's functions module emphasized) is a real, expected professional skill, not an optional extra.

Take Phase 11's Contact Book capstone and give it a genuine professional project structure: organized into multiple files, built with CMake, tracked with git, compiled with strict warnings enabled, and covered by at least one real unit test.

1. git init — start tracking the project (Module 3)
2. Split the single-file capstone into separate .h/.cpp files by responsibility — Contact's own logic separate from ContactBook's file-loading logic
3. Write CMakeLists.txt with -Wall -Wextra enabled from the very start (Module 4)
4. mkdir build && cd build && cmake .. && cmake --build . — the genuine build workflow (Module 1)
5. Write one real test verifying saveContacts/loadContacts genuinely round-trips correctly (Module 6)
6. git add . && git commit -m "Initial project structure" — the first real checkpoint (Module 3)