多くの環境で動く古いCのプロジェクトを、互換性を壊さずに直す

## 変更の前に、動かし続けるべき環境と機能の組み合わせを確かめる - 可搬性、安定性、堅牢性、後方互換性を主要な設計制約として扱う。 - 最小限の標準互換構成から、任意のスクリプトインターフェースを備えた完全なグラフィカル構成まで、幅広いビルドを考慮する。 - アーキテクチャや外部向け動作を変える前に、リポジトリの上位設計方針を読む。 - コアソース、ランタイム資産、翻訳、テスト、文書、サブプロジェクト、上流から取り込んだコードを区別する。 - 最新のコンパイラ、オペレーティングシステム、機能セット、グラフィカル環境を前提にしない。 - 変更が明示的に機能ゲートされていない限り、対応する各バリエーションの動作を一貫させる。 ## 変更に関わる構成をビルドし、新しい警告なしでテストを通す - 現在のプラットフォームとツールチェーンについて文書化されたビルド経路を使う。 - 関数宣言やその他の派生インターフェースは、生成済み出力を手作業で編集せず、ジェネレーターから再生成する。 - 反復作業中は対象を絞ったテストファイルを実行し、メッセージ出力と詳細なテストログの両方を確認する。 - 提出前に、新しい警告がないビルド、関連テストの合格、編集対象ファイルに合ったソーススタイルを必須とする。 - プラットフォームごとにビルド手順が異なる場合は、推測でコマンドを置き換えず、そのプラットフォームのインストールガイドを参照する。 - 共有コード、機能の組み合わせ、ランタイムファイルに影響する場合は、より広いテストへ拡大する。 ## 生成ファイルは生成元から作り直し、ファイルの担当者の流れに従う - どのディレクトリが生成物か、上流から取り込まれたものか、関連プロジェクトと共有されるか、指定保守担当者が管理するかを把握する。 - 生成ファイルは元ソースが変わった場合にだけ変更し、無関係な再生成を機能パッチへ混ぜない。 - 保守対象ランタイムの変更は、所有権を迂回せず、文書化された担当者ワークフローを通す。 - 配布されるランタイムファイルやヘルプファイルを編集した場合は、必要な変更日や説明を更新する。 - 明示的なディレクトリ例外を除き、コアソースの変更にはリポジトリで必須のパッチ追跡項目を追加する。 - ベンダー更新、生成ノイズ、翻訳、無関係なソース整理を1つのパッチへ決して混ぜない。 ## コミットの件名に、直し方ではなく問題を書く - リポジトリで定められたパッチ件名と本文の構造に厳密に従う。 - 件名には解決策の実装ではなく、問題を記述する。 - 完全な問題文と簡潔な解決文を、必須の帰属表記と句読点を付けて書く。 - 形式で求められる場合、任意の説明は必須の問題／解決ヘッダーの後に置き、箇条書きではなく文章で書く。 - 修正対象、終了対象、関連対象の参照を、それぞれ異なる意味に従ってラベル付けする。 - 必須の開発者証明を含め、AIによる支援は認められた共同作者の仕組みだけで明示する。 ## 今のCの書き方に合わせ、古いコンパイラが通らない構文を使わない - 4スペースの論理インデントを維持しつつ、ファイル固有のタブ規則またはスペースのみの規則に従う。 - 関数と制御フローでは、開始波括弧を独立した行へ置く。 - 関数定義の戻り値型と関数名を、リポジトリで確立された配置に整える。 - 便乗して現代化せず、周囲のファイルにおける宣言位置へ合わせる。 - 文書化された基準C言語と承認済みの新しい機能だけを使い、旧式コンパイラが対応しない構文を導入しない。 - 編集後はファイル固有のフォーマッターを実行し、その差分を確認する。 ## プロジェクトの型を使い、分かっている文字列の長さを関数に渡す - リポジトリ固有の型接尾辞を使い、システム標準で予約された接尾辞を避ける。 - 進行中の真偽値移行を維持する。1つのパッチ内ではその場所で確立された真偽値形式を一貫して使い、一括変換を避ける。 - 最初の代入が読み手にとって明白でない場合はローカル変数を初期化するが、未初期化読み取りの不具合を隠す冗長な初期化は加えない。 - 文字列リテラルにはリテラル長ヘルパーを使い、書き込みサイズが必要な場合は長さを返すフォーマッターを使う。 - 文字列長がすでに分かっている場合は、再走査せず、長さ認識操作へその値を渡す。 - 各バイトバッファのポインターは、その `size_t` 長と隣接させる。より狭い整数型は旧式インターフェースが要求する場合だけ使う。 ## プロジェクトのラッパーでメモリを扱い、エラーの時も必ず解放する - 標準ライブラリの生の確保、解放、コピー、移動、文字、空白操作より、リポジトリのラッパーを優先する。 - 文書化されたnull処理、メモリ不足時の動作、重複領域の安全性、エンコーディング動作、プラットフォーム間の一貫性に基づいてラッパーを選ぶ。 - 前段の複合条件から非ゼロだと推測できる場合でも、各除算の前に除数がゼロでないことを明示的に確認する。 - 新しい確保ごとに、成功、早期リターン、各エラー分岐のすべてで解放経路を検証する。 - バッファサイズはバイト単位で保持し、切り詰め、終端、書き込み済み長の動作を明示する。 - 一般的な呼び出しに慣れているという理由だけで、より安全なプロジェクトラッパーを汎用ライブラリ呼び出しへ置き換えない。 ## 名前とマクロの決まりを守り、どのmakeでも動くビルドファイルにする - 予約名の制限、禁止識別子、関数名の長さ上限、空白規則、1行1文の規則に従う。 - 確立された機能接頭辞と大文字マクロの規則を使う。 - リポジトリが対応する条件記述パターンで機能マクロを検査する。 - 主要ビルドファイルを文書化された可搬make方言の範囲に保ち、実装固有の代入、パターン、シェル、条件分岐の拡張を避ける。 - プロジェクトの文字列型とバイト型、および対応するマクロを再利用する。 - 新しい識別子、マクロ、ビルドルールを導入する前に、正本のスタイルリファレンスを読む。 ## 関連するランタイムや派生版でも動くランタイムスクリプトを書く - 新しいファイルでは現行のスクリプトスタイルを使いながら、関連ランタイムや派生版との互換性を考慮する。 - 互換性が不明な場合は、新しい言語構文を採用する前に確認する。 - スクリプトテストではローカル変数の命名規則に従う。 - ファイル全体ですでに機能ゲートしている場合は、個別テスト内で同じゲートを繰り返さない。 - ファイルに上位ゲートがない場合は、任意機能を必要とするテストだけに対象を絞ったゲートを追加する。 - ランタイムスクリプトの変更を、無関係なコア言語の現代化から分離する。 ## 報告された不具合をそのまま再現する回帰テストを書く - 単にプログラムがクラッシュしないことを確認するテストより、決定的なアサーションを優先する。 - 描画不具合には画面キャプチャ比較を追加し、データ誤りには正確な出力をアサートする。 - 新しい動作には包括的な範囲を追加し、可能なら既存の関連テストファイルに含める。 - 報告済み不具合を直す場合は、単純化した合成例だけでなく、元の状況を再現する。 - 端末セッション、画面ダンプ、スクリプト読み込み成功、想定されたスクリプト読み込み失敗には標準ヘルパーを使う。 - 構文とインデントのランタイムテストは、それぞれ専用のテスト群へ置く。 ## ヘルプ文書を同じパッチで直し、その書式を崩さない - オプションや機能の変更と同じパッチで、利用者向け文書を更新する。 - 既存文書を編集した場合は、ヘルプファイルの変更ヘッダーを更新する。 - ファイルヘッダー、モードライン、幅、タブ整列、一意なタグ、相互参照、見出し、コード例、強調表記について、正本のヘルプ形式を維持する。 - 安全な再タブ化操作を使って差分を確認し、広範な空白書き換えを強制しない。 - リンクタグを全体で一意に保ち、必要に応じて拡張機能固有のタグへ接頭辞を付ける。 - 新規または変更した文章ではジェンダー中立の表現を優先するが、その目的だけで影響を受けない文章を書き換えない。 ## リリースの時期を先に確かめ、非推奨の動作も使える形で残す - 変更範囲を提案する前に、プロジェクトが開発サイクル中か安定期間中かを確認する。 - 安定期間中に受け入れる変更は、明確な不具合修正、セキュリティ修正、文書、翻訳、ランタイム保守に限定する。 - 安定期間中は新機能や後方互換性を壊すコア変更を導入しない。 - リリース済みコアの動作をマイナーバージョン間で維持する。 - 非推奨の動作は設定経由で利用可能な状態を保ち、非推奨であることを文書化し、対応する場合はコンパイル時の無効化を許し、後の許可されたサイクルでのみ廃止する。 - コア保証を弱めず、ランタイム資産には文書化された保守上の柔軟性を適用する。 ## どのコミットも単独でビルドとテストが通るパッチを出す - 疑わしいセキュリティ問題を報告する前、またはセキュリティ上重要なコードを変える前に、セキュリティ方針を読む。 - コミット形式、警告のないビルド、関連テスト、回帰範囲、文書、証明がすべて完了していることを確認する。 - 差分を記載した問題に限定し、不要な空白変更、無関係なリファクタリング、無関係な生成出力を含めない。 - 複数パッチの系列では、各コミット単独でコンパイルとテストに合格することを必須とする。 - 後のコミットで直すことを前提に、意図的に壊れた中間コミットを残さず、1つにまとめる。 - 文書化された動作とコードが強制する動作が一致することを確認し、意図的な変更は問題／解決の記録に記述する。 ## 最小の変更にとどめ、作業ツリーの外に関わる操作は先に聞く - 目標を達成する最小の変更を行い、広範な改善を押し付けず、周囲のコードに合わせる。 - 複数の独立した問題を解決するパッチは分割する。 - パッチが症状だけに対処する場合は、より深い問題と選択した範囲制限を明記する。 - 不具合が存在すると主張する前に再現し、コードの動作を主張する前に実装を読む。 - 現在のソースを利用できる場合は、記憶しているファイル内容に依存しない。 - パッケージのインストール、作業ツリー外のファイル変更、ブランチのプッシュ、ネットワーク操作の前に利用者へ確認する。