★PostgreSQLカンファレンス2024 12月6日開催/チケット販売中★
他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

56.1. 書式 #

ソースコードの書式では、タブを4カラムとするスペーシングを使用し、現在はタブを保存しています(つまりタブをスペースに展開しません)。 各論理インデントのレベルは、さらに1つのタブストップです。

配置規則(括弧の位置など)はBSDの慣例に従います。 特にifwhileswitchなどの制御ブロックのための中括弧はそれ自身を一行で表します。

コードが80カラムのウィンドウで読み易くなるように1行の長さを制限してください。 (これは80カラムを超えてはならないことを意味していません。 例えば、任意の場所にある長いエラーメッセージ文字列をコードが80カラムに収まるように改行を含めても、おそらく可読性を向上させることはありません。)

一貫したコーディング形式を保つため、C++形式のコメント(//コメント)は使用しないでください。 pgindentは、それらを/* ... */で置き換えます。

複数行に渡るコメントブロックの推奨書式は以下のようになります。

/*
 * コメントテキストはここから始まり
 * ここまで続きます
 */

カラム1から始まるコメントブロックはpgindentによりそのまま維持されますが、字下げされたコメントブロックは、あたかも平文テキストのように再整形されることに注意してください。 ある字下げブロックの中で改行を維持したい場合は以下のようにダッシュを追加します。

    /*----------

     * コメントテキストはここから始まり
     * ここまで続きます
     *----------
     */

登録されたパッチは完全にはこの書式規則に従う必要はありませんが、そのようにすることを勧めます。 登録されるコードは次のリリースの前にpgindentを通します。 ですので、他の書式規則に従って作成して、見た目を良くすることに意味がありません。 優れたパッチに関する原則は、新しいコードがその前後にある既存のコードのように見えることです。

src/tools/editorsディレクトリには、確実に上記の規約に従った書式になることを補助する、Emacsxemacsvimエディタで使用できるサンプルの設定ファイルがあります。

pgindentをローカルで実行して、コードをプロジェクトスタイルに合わせたい場合は、src/tools/pgindentディレクトリを参照してください。

テキスト閲覧ツールmorelessでは以下のようにすれば、

more -x4
less -x4

タブを適切に表示させることができます。