C++ Programming Best Practices Flashcards

24 sample cards from the Best Practices deck

Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.

1. What is the key principle behind choosing good identifier names?

   Names should be self-documenting and intention-revealing: describe what the entity represents or does, so code reads clearly without extra comments. Favor clarity over brevity.

2. What is the difference between a `//` comment and a `/* */` comment in C++?

   `//` starts a single-line comment that runs to the end of the line. `/* */` delimits a block comment that can span multiple lines and cannot be nested.

3. What distinguishes a documentation comment from an ordinary implementation comment?

   Documentation comments (often `///` or `/** */` for Doxygen) describe the public interface — what a function/class does, its parameters, return value, and contract — for API consumers. Implementation comments explain the why of internal code for maintainers.

4. What is Doxygen, and name two common Doxygen tags.

   Doxygen is a tool that generates API documentation from specially formatted source comments. Common tags include `@param` (describe a parameter), `@return` (describe the return value), `@brief`, and `@throws`.

5. According to best practice, should comments explain what the code does or why it does it, and why?

   Comments should primarily explain the why (intent, rationale, trade-offs, non-obvious constraints). The what should be evident from well-named, clear code; restating it makes comments redundant and prone to going stale.

6. What is the main risk of over-commenting or leaving outdated comments?

   Redundant comments add noise, and outdated comments actively mislead readers because the compiler never checks them against the code, causing them to drift out of sync with behavior.

7. What is a unit test?

   A unit test is an automated test that verifies the smallest testable piece of code (typically a single function or class) in isolation, checking that given specific inputs it produces the expected outputs.

8. What do the three phases Arrange, Act, Assert (AAA) mean in a unit test?

   Arrange: set up the objects and inputs (fixtures). Act: invoke the function or behavior under test. Assert: verify the actual result matches the expected result.

9. What is a test fixture?

   A test fixture is the fixed baseline state and set-up code (objects, data, environment) established before running tests, so each test runs against a known, consistent context.

10. What is a mock object and why is it used in unit testing?

    A mock is a substitute for a real dependency that simulates its behavior and records interactions. It isolates the unit under test from external systems (databases, networks) and lets you verify how the unit uses its collaborators.

11. What does code coverage measure, and does 100% coverage guarantee correctness?

    Code coverage measures the percentage of code (lines, branches, functions) executed by the test suite. 100% coverage does not guarantee correctness — it only means code ran, not that all behaviors and edge cases were correctly asserted.

12. Name two popular C++ unit testing frameworks.

    Google Test (gtest), Catch2, Boost.Test, and doctest are widely used C++ unit testing frameworks.

13. In Test-Driven Development (TDD), what is the Red-Green-Refactor cycle?

    Red: write a failing test for new behavior. Green: write the minimum code to make it pass. Refactor: clean up the code while keeping the test passing. Repeat.

14. What is a regression test?

    A regression test verifies that previously working functionality still works after code changes, catching bugs (regressions) reintroduced by new development or refactoring.

15. Distinguish unit tests from integration tests.

    Unit tests verify a single component in isolation (dependencies mocked). Integration tests verify that multiple components work correctly together, including their real interactions and interfaces.

16. What is a breakpoint in a debugger?

    A breakpoint is a marker set at a specific line or condition that pauses program execution when reached, letting the developer inspect the current state (variables, call stack) at that point.

17. What is the difference between 'step into', 'step over', and 'step out' when debugging?

    Step into enters a called function to debug it line by line. Step over executes the called function as a single step without entering it. Step out runs the rest of the current function and returns to its caller.

18. Name two common command-line debuggers used with C++.

    GDB (GNU Debugger) and LLDB (the LLVM debugger). On Windows, the Visual Studio debugger / WinDbg are also common.

19. What is a watchpoint (data breakpoint) in debugging?

    A watchpoint pauses execution whenever the value of a specified variable or memory location changes (or is read), rather than when a particular line is reached, helping track down unexpected mutations.

20. What is a segmentation fault and a typical cause?

    A segmentation fault is a runtime error where a program accesses memory it is not allowed to. Typical causes include dereferencing a null or dangling pointer, out-of-bounds array access, or stack overflow.

21. What is Valgrind (or a memory sanitizer) used for in C++ debugging?

    Tools like Valgrind's Memcheck and compiler sanitizers (AddressSanitizer) detect memory errors at runtime — leaks, invalid reads/writes, use-after-free, and uninitialized memory access.

22. What is 'rubber duck debugging'?

    Rubber duck debugging is explaining your code line by line, out loud, to an inanimate object (a rubber duck). Articulating the logic forces you to examine assumptions and often reveals the bug yourself.

23. What does 'undefined behavior' (UB) mean in C++, and why does it make debugging hard?

    Undefined behavior is code whose result the C++ standard does not define (e.g., signed overflow, out-of-bounds access, use-after-free). Compilers may do anything, so programs can appear to work, crash randomly, or behave differently across builds, making bugs non-deterministic and hard to reproduce.

24. What is a core dump and how is it useful for debugging?

    A core dump is a file capturing a program's memory state at the moment it crashed. Loaded into a debugger (e.g., GDB), it lets you perform postmortem analysis — inspect the call stack and variables to find the cause of a crash after the fact.

What this deck covers

Best Practices flashcards FAQ