Project Architecture & Design
The final project is a fully functional, production-quality CLI task manager. It applies every concept from the course: structs for data modelling, dynamic arrays with realloc, binary file I/O for persistence, getopt_long for professional CLI parsing, const correctness throughout, goto for cleanup paths, valgrind-clean memory management, and a Makefile with debug/release modes.
Project Structure & Module Responsibilities
/* CLI Task Manager — Project Architecture
task-manager/
├── Makefile (Module 9 pattern: debug/release/test)
├── include/
│ ├── task.h (Task struct, TaskList, status enum)
│ ├── store.h (binary file persistence)
│ ├── display.h (formatted output)
│ └── cli.h (getopt argument parsing)
└── src/
├── task.c (task CRUD operations)
├── store.c (fread/fwrite binary I/O)
├── display.c (printf formatting)
├── cli.c (getopt_long parsing)
└── main.c (entry point, command dispatch)
Concepts applied per module:
Module 1: C compilation, gcc flags, make, -Wall -Wextra -std=c99
Module 2: switch dispatch in main, for loops in display.c
Module 3: functions with prototypes, scope, const parameters
Module 4: string handling: strncpy, strcmp, fgets for titles
Module 5: const Task *, Task ** for list manipulation
Module 6: malloc/realloc for TaskList, goto cleanup in store.c
Module 7: Task struct with Status enum, nested struct Date
Module 8: fread/fwrite binary database, fseek for updates
Module 9: Makefile, #ifdef DEBUG, include guards, __FILE__/__LINE__
Module 10: function pointers for sort comparators, bitwise for flags
Module 11: getopt_long, errno/perror, valgrind/ASAN verified
CLI Usage:
./taskman add "Buy groceries" --due=2026-12-31 --priority=high
./taskman list [--status=pending] [--sort=due]
./taskman done <id>
./taskman delete <id>
./taskman edit <id> --title="New title"
./taskman stats */Common Mistakes
- Putting all code in main.c — a 500-line main.c is unmaintainable. Split by responsibility: one file per module (store, display, CLI parsing, task operations).
- Over-engineering before writing any code — write a working single-file version first, then refactor into modules. Premature architecture leads to analysis paralysis.
- Not defining the data format first — design the binary file format (what bytes go where, how to handle future additions) before writing any I/O code.
Tip
Tip
Practice Project Architecture Design in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Understanding memory layout is essential for efficient C programming
Practice Task
Note
Practice Task — (1) Write a working example of Project Architecture Design from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with Project Architecture Design is skipping edge case testing — empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready c code.
Key Takeaways
- The final project is a fully functional, production-quality CLI task manager.
- Putting all code in main.c — a 500-line main.c is unmaintainable. Split by responsibility: one file per module (store, display, CLI parsing, task operations).
- Over-engineering before writing any code — write a working single-file version first, then refactor into modules. Premature architecture leads to analysis paralysis.
- Not defining the data format first — design the binary file format (what bytes go where, how to handle future additions) before writing any I/O code.