S00 門前の誓い_総合Index
1本だけ開いてみよう。今日の理解が、明日のトラブルを減らす。
このページは『C#達人への道(試練と掟)』の入口です。
狙いは2つだけ。
- いま困っている場面で、止血できる
- あとから読み返して、迷子にならない
まず読む順番(判断に迷ったら先に読む)
「最初の1クリック」をここで決める。迷ったらこの表だけ見て動く。
| いまの状況 | まず読む | 次に読む(理解を固める) |
|---|---|---|
| UIが固まる／止まる | E04 | G11 / G13 / R06 |
| NuGetや参照が壊れた | E02 | K27 / R01 |
| WinFormsの挙動が怪しい | E03 | G10 / R07 |
| 入力が壊れる(IME) | E05 | G14 / G15 |
| Win32を触る必要が出た | E06 | G12 / G16 / G17 |
| 外部通知が不安定 | E07 | R05 / K27 |
注: 未リンクのIDは…(準備中)。公開後にリンクへ差し替え。
カードで開く(迷ったらこの3本)
「表を読む気力が無い」時は、ここから1本だけ開く。
（公開済ならここを最優先）
新人〜中堅（詰まりやすい所だけ先に潰す）
ここは「年次」で区切る意図はない。
読めない／迷う／揉めるを減らすための入口。
補足: 読者の状態別の入口
| 読者の状態 | 最初に見る棚 | 理由 |
|---|---|---|
| 完全初心者 | S→E | 用語と状況整理→症状起点で成功体験が作れる |
| 現場で詰み始めた | E→R | 止血→再発防止(判断基準の固定)が最短 |
| 設計/運用まで踏み込みたい | R→K→G | 基準→手筋→原理の順が崩れにくい |
60秒要約(迷ったらここだけ)
- 記事はカテゴリ(S/E/R/K/G)で分類し、迷子を減らす
- 公開済はリンクが付く(IDは公開順ではない)
- 迷ったら「まず読む順番」だけ見て動く
- 止血はE、判断基準はR、手筋はK、納得して運用できるはG、地図はS
この目次の使い方(3つの入口)
- 症状起点: まず読む順番(症状→導線)
- 基準起点: R(掟)(レビューが揉める点を先に潰す)
- 体系起点: S(門前)→R(掟)→K(鍛錬)→G(外伝)
公開済(リンク)
現時点で公開済みの記事(リンクあり)。新規公開のたびにここへ追加します。
| ID | 概要 |
|---|---|
| S00 | 総合Index（門前の誓い） |
| S01 | 用語集（現場で詰む単語を先に潰す） |
| R01 | 門前の掟：命名/例外/ログ/依存の最小セット (コーディング規約) |
| R02 | varの使い分け基準: 迷いどころの明確化 |
| R03 | 文字列比較の掟：StringComparisonを明示して運用事故を減らす |
| R14 | _ (discard): out/戻り値を捨てる基準 |
| R04 | 例外設計：握り潰し禁止と throw; の作法 |
| R05 | ログ設計：再現不能を終わらせる三点セット |
| R06 | 非同期：UIスレッド/await帰還/デッドロック典型 |
| R07 | WinForms作法：ライフサイクル/Dispose/設計時安全 |
| K26 | ラムダ入門：delegate/Action/Func とクロージャ事故 |
| K27 | 運用で壊れない依存管理：参照地獄の終わらせ方 |
| K28 | float/double/decimal：精度と誤差の線引き |
| K29 | テキストフォーマット選定：CSV/TSV/JSON/XML/INI の使いどころ |
| K30 | シリアライズ設計：互換性/バージョン/セキュリティの落とし穴 |
| E02 | NuGet競合：参照崩壊の止血と恒久対策 |
| E04 | UIフリーズ：ループ/Invoke/async の即効薬 |
| E06 | 例外ログが残らず“突然終了”する：P/Invoke/WndProc/Handle寿命の最短切り分け |
| G11 | ループ入門：Application.Run と固まる理由 |
| G13 | UI×非同期：SynchronizationContext と帰還/デッドロック |
| G21 | 文字コード：UTF-8/Shift_JIS/BOM を疑う順番 |
前提(環境)
| 項目 | 前提 |
|---|---|
| OS | Windows 10/11 |
| .NET | .NET 8(Windows Desktop) |
| TargetFramework | net8.0-windows |
| UI | WinForms |
| IDE | Visual Studio 2026 / Visual Studio 2022(17.8以上推奨) |
| C# | C# 12(プロジェクトで固定推奨) |
補足: 本編は .NET 8 / WinForms / net8.0-windows を正とし、実務上の差分が有意な場合のみ .NET Framework 4.8 を折りたたみで併記。
記号(S/G/E/R/K)の意味(棚の分類)
記事IDの先頭1文字でカテゴリ(棚)を表す。
この記号体系は本シリーズ内の便宜上のもの。外部の一般用語ではない。
補足: GEAR-K(内部呼称)
- S/E/R/K/Gの棚記号をまとめて呼ぶための内部呼称。
- G/E/R/K部分を読みやすくした呼称がGEAR-K(Aはカテゴリではなくつなぎ音)。
- どちらも一般用語ではなく、本シリーズ内の便宜上の呼び名。
加えて、IDは公開順ではない。
公開済の記事は、上の「公開済(リンク)」一覧にだけリンクが並ぶ。
リンクがないIDは準備中。
棚(カテゴリ)一覧
| 記号 | 棚(カテゴリ) | 何が読めるか(一言) | 由来(覚え方) | 例 |
|---|---|---|---|---|
| S | 門前(導入/前提) | 迷子防止・前提を先に潰す | S = Start / Setup | S00(本ページ), S01 |
| G | 外伝(深掘り/深淵) | 納得して運用できるするまで深掘り | G = Gaiden | G11, G13 |
| E | 現場救急Tips | 症状から最短で止血 | E = Emergency | E04, E06, E07 |
| R | 掟(ルール/判例) | 判断基準を固定 | R = Rule | R01, R06 |
| K | 鍛錬(ノウハウ) | 分離/配布/依存運用 | K = Know-how | K21, K27 |
迷ったときの分類基準(最短判定)
- S: 前提を揃える／用語のズレを潰す／全体の地図を渡す(迷子防止)
- E: 症状から最短で止血する(今すぐ直す・復旧する)
- R: 判断基準を固定して揉めない(規約・判例・レビュー基準)
- K: 分離・配布・依存運用など、再現性のある手筋を鍛える
- G: なぜそうなるかを納得して運用できるさせる(原理・背景・深掘り)
補足(運用ルール)
- 1つの記事に複数要素が混ざる場合は、主目的(読後に得たい成果)が最も強い棚を採用
- 例: 深掘り(G)が入っていても「まず止血」が主目的ならE
- Eは短距離走、Gは長距離走。状況で使い分ける
このシリーズの読み方(各記事の共通構成)
見出し構成を固定し、「必要な情報へ最短で辿れる」状態を作る。
| 区分 | この記事で出てくる見出し(概ね固定) |
|---|---|
| 学習回(G/R/K) | 導入 / 掟 / 試練(必須・発展・地獄) / 血と汗の成果物(表・最小コード) / 容赦なき断罪(レビュー観点) / 次なる試練(関連導線) |
| 救急回(E) | 断末魔(症状) / 真犯人(原因) / 処方箋(最短手順) / 追い討ち(ハマり) / 再発防止の掟(ルール化) / 関連導線 / 禁書庫(即効チェック) |
ラインナップ(準備中含む)
状態：✓ 公開済 / … 準備中
一覧を開く
- 状態が「…」のものは、公開後にリンクへ差し替え。
S：門前(導入／前提)
| ID | タイトル | ひとことで | 状態 |
|---|---|---|---|
| S00 | 門前の誓い(総合Index) | 全体の地図と関連導線 | ✓ |
| S01 | 用語集(現場で詰む単語を先に潰す) | 「言葉のズレ」で詰まないための辞書 | ✓ |
E：現場救急Tips(症状→止血)
| ID | タイトル | ひとことで | 状態 |
|---|---|---|---|
| E01 | 環境構築で詰まない：.NET 8 SDK / VS / テンプレ / ターゲットの最短整合 | 最初の地雷を踏まないための整合チェック | … |
| E02 | 依存関係が壊れる：参照 / NuGet / バージョン競合の止血と恒久対策 | 参照地獄の出火点を特定して止血する | ✓ |
| E03 | WinFormsが言うことを聞かない：イベント順 / 描画 / レイアウト / トレイ / 多重起動 | “挙動不審”を再現と観測で切り分ける | … |
| E04 | UIフリーズの正体：メッセージループ / Invoke / async の即効薬 | 固まったUIを最短で動かす | ✓ |
| E05 | IMEが壊れる：確定が飛ぶ / 文字が消える / フォーカス地獄の切り分け | 入力周りの事故を切り分ける | … |
| E06 | 例外ログが残らず“突然終了”する：P/Invoke/WndProc/Handle寿命の最短切り分け | “消えた”をP/Invoke/WndProc/Handle寿命で切り分ける | ✓ |
| E07 | 外部通知が死ぬ：Webhook / プロキシ / タイムアウト / リトライ設計の止血 | 通知の“死”をネットワーク観点で止血する | … |
| E08 | 参照地獄の発火点：公開API / バージョン / 配布差の事故パターン | 配布差分の事故を型で潰す | … |
| E09 | 回帰を止める：事故の型に寄せたテストと運用の最短整備 | 再発防止を“最小コスト”で回す | … |
R：掟(ルール／判例)
| ID | タイトル | ひとことで | 状態 |
|---|---|---|---|
| R01 | 門前の掟：命名・例外・ログ・依存で揉めないための最小セット | 議論を終わらせる“最小ルールセット” | ✓ |
| R02 | varの使い分け基準: 迷いどころの明確化 | 型推論と可読性の線引き | ✓ |
| R03 | 文字列比較の掟：StringComparisonを明示して運用事故を減らす | カルチャ依存バグを根絶する | ✓ |
| R04 | 例外設計の掟：throw; と握り潰し禁止、境界での変換 | 調査可能な例外に“設計”する | ✓ |
| R05 | ログ設計の掟：ILogger・構造化ログ・レベル運用 | ログを“調査コスト削減装置”にする | ✓ |
| R06 | 非同期の掟：UIスレッド、awaitの帰還、デッドロック典型 | フリーズの地雷原をマップ化する | ✓ |
| R14 | _ (discard) の使いどころ: out/戻り値を捨てる基準 | 捨てる意図と線引き | ✓ |
| R07 | WinForms作法の掟：ライフサイクル・Dispose・設計時安全 | 設計時事故と解放漏れを潰す | ✓ |
| R08 | 分離の掟：後でDLLに切り出せる境界の作り方 | 変更に強い境界の作り方を固定する | … |
K：鍛錬(ノウハウ)
| ID | タイトル | ひとことで | 状態 |
|---|---|---|---|
| K21 | クラスライブラリ(DLL)の作り方：net8.0 で壊れにくい最小分離 | 分離の“最小手順” | … |
| K22 | UIとロジックの分離：WinForms から Domain / Application へ逃がす型 | 責務の逃がし方 | … |
| K23 | 公開API設計：破壊的変更を避けるバージョニング | 配布運用を壊さない設計 | … |
| K24 | テスト容易性：DI / モック / インターフェース設計の型 | テスト可能な設計に寄せる | … |
| K25 | 配布の鍛錬：ローカルDLLから内部NuGet化へ寄せる | 配布を“手作業”から卒業する | … |
| K26 | ラムダ式入門：匿名関数 / delegate / Action / Func / キャプチャ | 読める形に復元して事故を減らす | ✓ |
| K27 | 運用で壊れない依存管理：参照地獄の終わらせ方 | 依存運用の方針を固める | ✓ |
| K28 | float / double / decimal の選び方：精度と計算誤差で事故らない | 数値の事故を防ぐ判断基準 | ✓ |
| K29 | テキストフォーマット選定：CSV / TSV / JSON / XML / INI の使いどころ | フォーマット選定の地雷を避ける | ✓ |
| K30 | シリアライズ設計：互換性 / バージョン / セキュリティの落とし穴 | データ互換と安全性の勘所 | ✓ |
| K31 | 画像リソース形式の選び方：png / jpg / svg / bmp / ico で迷わない | 画像形式の“正しい迷い方” | … |
| K32 | コントロール継承入門：数字のみ入力 / ちらつき抑制 / デザイナ互換 | WinForms部品化の実戦 | … |
| K33 | 文字列操作早見表：検索 / 置換 / 分割 / 結合 / 正規表現を事故らせない | 文字列処理の実務テンプレ | … |
| K34 | クリップボード操作の作法：STA / Invoke / リトライで事故らない | クリップボード事故の最小対策 | … |
G：外伝(深掘り／深淵)
| ID | タイトル | ひとことで | 状態 |
|---|---|---|---|
| G10 | Formライフサイクル実戦：Load / Shown / Closing / Dispose の責務分割 | 画面の寿命設計を納得して運用できるさせる | … |
| G11 | メッセージループ入門：Application.Run と UI が固まる本当の理由 | UIフリーズの原理を掴む | ✓ |
| G12 | Win32メッセージ基礎：WndProc / WM_* / DefWndProc の最小フック | Win32の“入口”を最低限押さえる | … |
| G13 | UIスレッドと非同期の実戦：SynchronizationContext / await の帰還 / デッドロック典型を潰す | 事故の再現→言語化→潰し込み | ✓ |
| G14 | IME地獄の設計：ImeMode / フォーカス遷移 / WM_IME の対症療法を固定する | IME事故を“設計”で封じる | … |
| G15 | コントロール設計とデザイナ：継承 / プロパティ表示 / 設計時例外を潰す型 | Designer互換の作法 | … |
| G16 | 最前面・Zオーダー・フォーカス：SetWindowPos / TopMost の通知UI設計 | 最前面は“副作用込み”で設計する | … |
| G17 | 低レベル入力とホットキー：RegisterHotKey の競合 / 解除漏れ / テスト観点 | ホットキー事故の典型を潰す | … |
| G18 | 多重起動制御の作法：Mutex と既存インスタンス前面化(運用で壊さない) | 多重起動の事故を“仕様”にする | … |
| G19 | トレイ常駐の作法：NotifyIcon の終了導線と復帰導線 | 常駐アプリの“戻れない”を潰す | … |
| G20 | SendMessage と PostMessage：メッセージキュー / 同期 / 非同期を踏み抜かない | 同期・非同期の誤解をなくす | … |
| G21 | 文字コード入門：UTF-8 / Shift_JIS / BOM / 1文字は1バイトではない | 文字化け事故の基礎体力 | ✓ |
| G22 | 時間とタイムゾーン：UTC / JST / DateTime / DateTimeOffset で事故を止める | 時刻の事故を根から止める | … |
| G23 | ネットワーク基礎：TCP / UDP の違いと使いどころを誤解しない | 通信の“前提”を固める | … |
| G24 | P2P の仕組み：NAT越え / STUN / TURN / リレーを図で納得して運用できるさせる | NAT越えの納得して運用できる | … |
| G25 | MVC：責務分割で Fat Controller と Smart View を避ける | 分離の地図(Web系の足場) | … |
| G26 | MVP：WinForms の現実解 — Presenter と View IF の境界を壊さない | WinFormsに合う分離の型 | … |
| G27 | MVVM：Binding 地獄を避ける — ViewModel / State / Command の設計 | 状態と操作を整理する型 | … |
このIndexの運用方針
このIndexの役割は「迷子を減らす」こと。
カテゴリ(S/E/R/K/G)で分類し、公開済は上の「公開済(リンク)」一覧で追う。
-
公開済の記事は、上の「公開済(リンク)」一覧が最新
-
迷ったら「まず読む順番」→E(止血)→G(理解)→R(再発防止)
-
起点は「UIフリーズ」(遭遇率と損失が大きい)
-
E04: UIフリーズの止血(最短手順／計測)
-
G11: なぜ固まるか(メッセージループの構造)
-
G13: 帰還先／同期ブロック／デッドロック典型(実戦整理)
-
R06: ルールとして根絶(レビュー基準)
謝辞(O’Reilly／オライリー風)(読みたい人だけ)
この連載は、目に見える協力者と、目に見えない協力者と、そして「見えないふりをしている協力者」たちの力で成立しています。
まず、部屋のホコリと、キーボードの隙間に挟まった謎の白い粉に感謝します。
その存在があるからこそ、私は定期的に掃除をし、結果として思考も整理されます。
次に、地球上の全ての生物に感謝します。だいたい全部です。
見えないものほど、あとから効いてくる。開発も同じです。
前提と依存を疑う。これをプログラマの義務教育と呼びます。
そして、終わらない締切、終わらないリビルド、終わらない「ちょっとだけ直す」、終わらない確認にも感謝します。
夜は静かで、朝は眩しく、昼は眠く、夕方は焦る。全部セットで、なぜか仕事は進みます。
ドはまりした案件ほど、人は鍛えられて、設計と言葉が強くなります。ありがたい。実にありがたい。
ただし、同じ成長は別ルートがよい。次は普通に成長したいです。
さらに、堅牢すぎて時々こちらの正気まで守ってくれるセキュリティにも感謝します。
社内に「外から見られる仕組み」を気軽に作れず、ナレッジが社内の奥深くに封印され、しかもお客様の環境から自社ネットワークに入って作業する構図に、たまに哲学的な違和感が生まれる。
その結果、私は個人でQiitaに技術メモを残す必要が出ました。
公開できないことは書かない。公開できることだけを、ちゃんと磨く。
制約は多いほど、文章は強くなります。
関係者各位、心配は不要。ここにあるのは“漏れて困るもの”ではなく、“漏れて助かるもの”だけです。
最後に、我が家のミニチュアダックスフント「びび」に特別な謝意を。
この連載の本当の締切は、びびの散歩です。
机の下から見上げる目が「まだ書けるだろ」と言い、リードの音が「そろそろ出せ」と言い、玄関の気配が「公開しろ」と言います。
そして、玄関で尻尾が一度だけ動く。
プログラムは、書いた通りにしか動かない。
例外もバグも、原因は「書いていない前提」と「仕様(OS/フレームワーク)の見落とし」に収束する。
動くコードは最低条件。保守され、トラブルを減らし、次の変更に耐えてこそ現場で使える。