構造化設定：記号ではなく値を変える

専用ツールの方が簡単になる理由

大きな設定ファイルで application.debug だけ変えたいなら、正しい箇所を探してカンマや括弧を守るより、論理パスをそのまま指定する方が明確です。

複数形式に共通するリズム

形式モジュールは似た文法を持ちます。開く、キーを読む、検索する、: で書く、削除する、-c で検証する、dump でシリアライズする、という流れです。開いた後は $ でアクティブファイルを表せます。

INI：セクションと単純な値

INI はキーと値をセクションにまとめます。ドットパスを使えば、ファイル全体をスクロールせずに論理値へ直接アクセスできます。

JSON：オブジェクト、配列、型

この練習では code -n で project/config/app.json を開き、下にある {} の初期内容を貼り付けて保存してから json コマンドを実行します。構造化エディタは、最初から有効な JSON を必要とします。

JSON は API、メタデータ、アプリ設定で広く使われます。パス指定の変更はカンマや括弧の誤りを減らし、-c で明示的に検証できます。

{}

YAML、TOML、XML、conf、properties

YAML はインデント、TOML はテーブルと型、XML は要素と属性、conf/properties はキー・値系の表現を中心にします。lil は日常操作を近づけますが、形式が同一だとは扱いません。

検証し、ソースが必要な時だけ `dump`

-c は文書を検証し、dump はシリアライズしたソース表現を返します。構造化書き込みで書式やコメントが正規化される場合があります。文字列としての形が重要なら edit または code を使います。

`code` に戻るタイミング

形式モジュールは値の変更、検索、検証に向きます。コメント、厳密な整形、高度な形式機能が重要なら code が適しています。

設定変更はスクリプトに残す価値が高い

検証済みの設定手順は実行できる文書になります。次のプロジェクトで読み直し、必要な値だけ変え、同じ環境を再現できます。