Contents
スポンサードリンク
学習全体像と日別目標（Day0 〜 Day7）
このセクションは、1 週間で実務レベルの C プログラミングスキルを構築するためのロードマップです。
目的 は「環境構築 → 基本文法 → メモリ管理 → エラーハンドリング → テスト → Git 管理 → 完成プロジェクト」のサイクルを回すことにあります。
| Day | 学習テーマ | 主なアウトプット |
|---|---|---|
| Day0 | 開発環境のインストールと設定 | VS Code とコンパイラが動く状態 |
| Day1 | C23 の基本文法（変数・データ型・制御構造） | Hello, World＋標準入力取得プログラム |
| Day2 | 関数定義とヘッダー分割 | int add(int a, int b) を実装しテスト |
| Day3 | ポインタと動的メモリ管理（malloc / free） | 動的配列で整数の合計を算出 |
| Day4 | 標準ライブラリ活用とエラーハンドリング | fopen と errno を使ったファイル読み込み例 |
| Day5 | ユニットテスト入門（Unity） | add 関数の Unity テストを書いて実行 |
| Day6 | Git フローとコードレビューシミュレーション | ブランチ作成・PR テンプレート作成・マージ |
| Day7 | ミニプロジェクト：TODO CLI ツール完成 | ファイル入出力、動的配列、テスト、Git 管理をすべて実装 |
ポイント
1 週間で「環境構築 → 基本文法 → メモリ管理 → エラーハンドリング → テスト → Git 管理 → 実践プロジェクト」の流れを経験するだけで、実務に直結する基礎が確実に身につきます。
開発環境の構築
VS Code のインストールと推奨拡張機能
VS Code は軽量かつ拡張性が高く、C 言語開発でも広く利用されています。以下は導入手順と最低限必要な拡張機能です。
- ダウンロード
-
公式サイト https://code.visualstudio.com/ から OS に合わせたインストーラを取得します。
-
インストール
-
デフォルト設定でインストールし、起動後に「拡張機能」ビュー（左側の四角形アイコン）へ移ります。
-
必須拡張機能（Marketplace 推奨）
| 拡張機能 | 主な機能 |
|---|---|
| C/C++ (Microsoft) | IntelliSense、デバッグ、コードナビゲーション |
| CMake Tools | CMake プロジェクトの自動生成・ビルド |
| CodeLLDB | LLDB デバッガ連携（macOS / Linux 推奨） |
| GitLens | Git の可視化と履歴管理 |
- settings.json の基本設定
json
{
"C_Cpp.intelliSenseEngine": "Default",
"cmake.generator": "Ninja",
"files.associations": { "*.c": "c" },
"editor.formatOnSave": true
}
コンパイラ取得と PATH 設定
| OS | 推奨インストール方法 |
|---|---|
| Windows | - MSYS2：pacman -S mingw-w64-x86_64-gcc mingw-w64-x86_64-clang - Chocolatey（補助的）: choco install mingw llvm |
| macOS | Homebrew：brew install gcc llvm |
| Ubuntu / Debian 系 | APT：sudo apt update && sudo apt install build-essential clang |
PATH 設定例
- Linux/macOS（bash/zsh）
bash
# .bashrc または .zshrc に追記
export PATH="/usr/local/opt/llvm/bin:$PATH" # clang
export PATH="/usr/local/opt/gcc/bin:$PATH" # gcc - Windows（PowerShell）
powershell
$env:Path += ";C:\msys64\mingw64\bin;C:\msys64\usr\bin"
VS Code ビルドタスクのサンプル
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
{ "version": "2.0.0", "tasks": [ { "label": "Build with GCC", "type": "shell", "command": "gcc", "args": ["-Wall", "-Wextra", "-std=c23", "${file}", "-o", "${fileBasenameNoExtension}"], "group": "build", "problemMatcher": ["$gcc"] }, { "label": "Build with Clang", "type": "shell", "command": "clang", "args": ["-Wall", "-Wextra", "-std=c23", "${file}", "-o", "${fileBasenameNoExtension}"], "group": "build", "problemMatcher": ["$gcc"] } ] } |
まとめ
VS Code と最新の GCC／Clang が正しく PATH に通っていれば、エディタ上だけでコード補完・デバッグ・ビルドが完結します。
C23 の基礎知識と実践的言語要素
この章では、実務で頻出する構文・メモリ操作・エラーハンドリングに絞って解説します。C23 でも従来の C99/C11 と互換性が保たれる点を意識しながら学習してください。
基本文法とデータ型（bool の取り扱い）
bool は C23 でも標準ではありますが、
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
#include <stdio.h> #include <stdbool.h> int main(void) { int count = 0; double rate = 3.14; bool flag = true; // <stdbool.h> が必須 for (int i = 0; i < 5; ++i) { if (flag) { printf("Iteration %d, rate=%.2f\n", i, rate); } } return 0; } |
- 変数は宣言時に必ず初期化し、未定義動作を防止します。
- 制御構造は
for,while,do...whileに加えて従来通りのswitchが利用可能です（C23 の pattern matching はまだ実装段階）。
ポインタと動的メモリ管理
メモリ確保・解放の安全パターンを示します。失敗時は必ずエラーメッセージを出力し、ポインタを NULL にリセットします。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
#include <stdio.h> #include <stdlib.h> int *create_array(size_t n) { int *arr = malloc(n * sizeof(int)); if (!arr) { perror("malloc"); return NULL; } for (size_t i = 0; i < n; ++i) arr[i] = (int)i; return arr; } void free_array(int **p) { if (p && *p) { free(*p); *p = NULL; // ダングリングポインタ防止 } } |
標準ライブラリ活用例
| ライブラリ | 主な機能 |
|---|---|
| stdio.h | 入出力 (printf, scanf, fgets) |
| stdlib.h | 動的メモリ、乱数、環境変数取得 |
| string.h | 文字列操作（strcpy, strlen, memcpy） |
CSV 行の分割例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
#include <stdio.h> #include <string.h> void parse_csv_line(const char *line) { char buf[256]; strncpy(buf, line, sizeof(buf) - 1); buf[sizeof(buf) - 1] = '\0'; char *token = strtok(buf, ","); while (token) { printf("Field: %s\n", token); token = strtok(NULL, ","); } } |
エラーハンドリングのベストプラクティス
errno はスレッドローカルで保持されるため、取得直後に文字列化するのが安全です。関数は 0 成功 / -1 失敗 の形で統一するとテストコードがシンプルになります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
#include <stdio.h> #include <errno.h> #include <string.h> int read_file(const char *path) { FILE *fp = fopen(path, "r"); if (!fp) { int err = errno; fprintf(stderr, "Error opening %s: %s\n", path, strerror(err)); return -1; } /* ファイル処理 */ fclose(fp); return 0; } |
まとめ
正しいデータ型のインクルード、メモリ確保失敗時のチェック、エラーメッセージの一貫性は実務でバグを減らす最も基本的な手法です。
テストとバージョン管理の実践
テストコードと Git フローは品質保証に不可欠です。この章では Unity と CMocka の選択基準、実装例、そして PR プロセスを具体的に示します。
ユニットテストフレームワークの選択基準
| 基準 | Unity | CMocka |
|---|---|---|
| 導入コスト | ソース単体で完結（外部依存が少ない） | ライブラリとしてリンク、pkg‑config が必要 |
| CMake 互換性 | 高い（unity.c をソースに組み込める） | 中程度（find_package(CMocka) が必要） |
| 学習曲線 | 初心者向けのシンプル API | 若干高度なモック機能がある |
| 推奨用途 | 小規模・組込み系プロジェクト | 大規模テストスイートやモックが必須の場合 |
実務で「すぐに書き始めたい」なら Unity、既存の CMocka 環境が社内にある場合は CMocka を選択してください。
Unity を使ったユニットテスト例
以下は add 関数を対象とした最小構成です。Unity のソース (unity.c, unity.h) はプロジェクトの third_party/ ディレクトリに配置します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
/* add.c */ int add(int a, int b) { return a + b; } /* test_add.c */ #include "unity.h" extern int add(int, int); void setUp(void) {} void tearDown(void) {} void test_Add_Positive(void) { TEST_ASSERT_EQUAL_INT(5, add(2, 3)); } void test_Add_Negative(void) { TEST_ASSERT_EQUAL_INT(-1, add(-2, 1)); } /* runner.c */ #include "unity.h" int main(void) { UNITY_BEGIN(); RUN_TEST(test_Add_Positive); RUN_TEST(test_Add_Negative); return UNITY_END(); } |
CMake ビルド設定
|
1 2 3 4 5 6 7 8 9 |
cmake_minimum_required(VERSION 3.20) project(todolist C) add_library(unity STATIC third_party/unity.c) target_include_directories(unity PUBLIC third_party) add_executable(add_test test_add.c add.c runner.c) target_link_libraries(add_test PRIVATE unity) |
make → ./add_test でテスト結果がコンソールに表示されます。
Git フローとプルリクエストテンプレート
- リポジトリ初期化
bash
git init todo-cli
cd todo-cli -
main ブランチ保護（GitHub 設定例） – 直接 push を禁止し、PR 経由でのみマージできるようにします。
-
機能ブランチ作成とコミット規約
bash
git checkout -b feature/add-item
# 作業後
git add .
git commit -m "feat: implement add command" -
プルリクエストテンプレート (
.github/pull_request_template.md)
|
1 2 3 4 5 6 7 8 9 10 11 |
## 変更概要 - 実装した機能／修正点を簡潔に記述 ## テスト結果 - `make test` の実行ログ（抜粋可） ## チェックリスト - [ ] ビルドが成功する - [ ] ユニットテストがすべて通る - [ ] clang-format に準拠している |
- レビューサイクル
- コメントで指摘 →
git commit --amendで修正 → 再度 PR 更新。
ポイント
Unity テストと Git フローを同時に体験することで、テスト駆動開発（TDD）の効果とコードレビューの重要性が実感できます。
Day0 〜 Day7 の詳細スケジュール
Day0：環境構築
- VS Code とコンパイラをインストールし、PATH を設定。
git --versionとgcc -vが正常に表示されることを確認。
Day1：C23 基本文法
- 変数・データ型（bool は
<stdbool.h>必須）と制御構造を学習。 - 「Hello, World」＋標準入力取得プログラムを書き、コンパイル成功を体感。
Day2：関数とヘッダー分割
add.cとadd.hに分けて実装し、インクルードガードの書き方を確認。- ヘッダーは他ファイルからも利用できることを確認するテストを書きます。
Day3：ポインタと動的メモリ
malloc/freeの失敗チェック、二段階解放パターンを実装。- 動的配列で整数の総和を求め、Valgrind（Linux/macOS）または Dr.Memory（Windows）でメモリリーク検出。
Day4：標準ライブラリとエラーハンドリング
fopen/fcloseとerrnoを組み合わせたファイル読み込み例を実装。- エラー情報は
strerror(errno)で文字列化し、標準エラー出力に表示。
Day5：ユニットテスト（Unity）
- 前日作成した
add関数の Unity テストを書き、CI ツール（GitHub Actions）で自動実行。 - テストが失敗した場合はコンパイルエラーと同様に CI がビルドを停止します。
Day6：Git フロー体験
feature/todo-cliブランチで TODO CLI の骨格コードを書き、PR を作成。- PR テンプレートにテスト結果・ビルドログを必ず添付し、レビュー担当者がチェックできるようにします。
Day7：ミニプロジェクト完成
- 完全な TODO CLI ツール（add / list / done）を実装。
todos.txtに CSV 形式で永続化し、起動時に自動ロード。- 最終的に GitHub 上で
v1.0.0タグを付与して完了。
総括
このサイクルを通じて「環境構築 → 基本文法 → メモリ管理 → エラーハンドリング → テスト → バージョン管理 → 完成プロジェクト」の一連の流れが体得できます。
ミニプロジェクト：TODO CLI ツール
要件定義と設計方針
| コマンド | 目的 |
|---|---|
todo add "task" |
新規タスクを追加し、ID を自動付与 |
todo list |
全タスクを ID 順に表示（完了フラグも併記） |
todo done <id> |
指定 ID のタスクを完了状態に変更 |
- データ構造は struct Todo と動的配列で管理。
- 永続化は同ディレクトリの
todos.txtに CSV 形式で保存し、起動時にロードします。
実装コード抜粋（C23, 必須）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 |
#include <stdio.h> #include <stdlib.h> #include <string.h> #include <stdbool.h> typedef struct { int id; char *text; bool done; } Todo; /* グローバル配列と要素数 */ static Todo *g_todos = NULL; static size_t g_count = 0; /* タスク追加 */ int todo_add(const char *txt) { if (!txt || txt[0] == '\0') return -1; // 無効入力 Todo *tmp = realloc(g_todos, (g_count + 1) * sizeof(Todo)); if (!tmp) return -2; // メモリ確保失敗 g_todos = tmp; g_todos[g_count].id = (int)(g_count + 1); g_todos[g_count].text = strdup(txt); g_todos[g_count].done = false; ++g_count; return 0; } /* CSV 形式で永続化 */ int todo_save(const char *path) { FILE *fp = fopen(path, "w"); if (!fp) return -1; for (size_t i = 0; i < g_count; ++i) fprintf(fp, "%d,%s,%d\n", g_todos[i].id, g_todos[i].text, g_todos[i].done); fclose(fp); return 0; } /* CSV 読み込み */ int todo_load(const char *path) { FILE *fp = fopen(path, "r"); if (!fp) return -1; // ファイル未存在は無視しても可 char line[256]; while (fgets(line, sizeof(line), fp)) { int id, done; char text[128]; if (sscanf(line, "%d,%127[^,],%d", &id, text, &done) == 3) { todo_add(text); g_todos[g_count - 1].id = id; // 読み込んだ ID を保持 g_todos[g_count - 1].done = (bool)done; } } fclose(fp); return 0; } |
Unity テスト例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
#include "unity.h" extern int todo_add(const char *); extern size_t g_count; extern Todo *g_todos; void setUp(void) { // 各テスト前に状態リセット free(g_todos); g_todos = NULL; g_count = 0; } void tearDown(void) {} void test_Todo_Add_Valid(void) { TEST_ASSERT_EQUAL_INT(0, todo_add("Buy milk")); TEST_ASSERT_EQUAL_SIZE_T(1, g_count); TEST_ASSERT_NOT_NULL(g_todos[0].text); TEST_ASSERT_FALSE(g_todos[0].done); } void test_Todo_Add_Empty(void) { TEST_ASSERT_EQUAL_INT(-1, todo_add("")); } |
Git 管理手順
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
git init git checkout -b feature/todo-cli # 作業後 git add . git commit -m "feat: implement basic TODO CLI" git push origin feature/todo-cli # リモートリポジトリへ送信 # GitHub 上で PR を作成 → テンプレートにテスト結果・ビルドログを記載 # 承認後 main にマージ、タグ付与 git checkout main git merge --no-ff feature/todo-cli git tag -a v1.0.0 -m "First release of TODO CLI" git push origin main --tags |
ポイント
1 ファイル入出力、動的配列、テスト、Git のすべてを同時に体験できるので、実務で要求される「品質・保守性・チーム開発」の感覚が養われます。
学習後のステップと追加リソース
アルゴリズム演習
- LeetCode の C タグで Easy/Medium 問題を 1 日 2問程度解く。
qsort、bsearch、文字列操作は標準ライブラリ活用で実装練習。
コード品質向上策
| ツール | 用途 |
|---|---|
| clang-tidy | 静的解析で未使用変数・バッファオーバーランを検出 |
| clang-format | 統一されたコードスタイルの自動適用 |
| GitHub Actions | CI にビルド＋テスト＋clang‑tidy を組み込み、プッシュ時に自動チェック |
業務ドメイン知識取得
- 自社製品のログフォーマットや設定ファイル（JSON／CSV）を C でパースする小ツールを書いてみる。
- オープンソース CLI ツール（例：
htop,jq）のコードリーディングで実装テクニックを吸収。
最終まとめ
- 環境構築 → VS Code + GCC/Clang が整えばすぐにコーディング開始。
- C23 の基礎 では
<stdbool.h>を忘れずインクルードし、メモリ確保失敗は必ずチェック。 - テストと Git フロー は Unity（または CMocka）＋ PR テンプレートで標準化。
- Day0〜Day7 のカリキュラム を順に実行すれば、実務で必要なスキルが体系的に習得できる。
- TODO CLI プロジェクト で学んだ要素を総合的に活用し、完成後はアルゴリズム・コード品質ツールでさらにレベルアップ。
このロードマップ通りに進めば、1 週間で「書く」「テストする」「管理する」すべての工程が体感でき、実務プロジェクトへの即戦力として活躍できる基盤が確立します。次のステップは、ここで得た知識を日常的な開発タスクに応用し、継続的に学習サイクルを回すことです。
スポンサードリンク