はじめにRedはコードがデータとして表現される同図象性を持つ言語です。その特性の結果として、どんな形でもデータを取り扱えるよう、言語はほぼ完全なフリーフォームとなっていて、またDSL特有のフォーマッティングのニーズを叶える柔軟性を持っています。膨大な方法の1つでしかありません。従ってGithubのred/redリポジトリにサブミットされる全てのプルリクエストはこのコーディングスタイルに準拠する必要があります。Red/SystemはRedのダイアレクトであり、Redと同じシンタックス、コーディングスタイルルールを共有します。Red/System固有のルールはそのように記載がされます。以下のルールの目的は、コメントの必要性を最小にし、スクリーン上に見えるコードの行数を最適に維持することなど、可読性を最大化することです。1行のコードの長さ1行のコードに対して最大何文字とするかの厳格な定義はありません。使用されているフォントタイプ(サイズやプロポーショナル、固定長の違いなど)やハイライト効果によっても異なるからです。1080ポイントのモニターの半分の幅で、エディタ上で1行の全てのコード(コメントを含めた)が読めるようにするべきです。私達がRedのコードベースをコーディングしているディスプレイ上では、概ね100文字です。表現は前述の基準に違反するコードサイズの行になるでしょう。文字のタブを使用しています。これは小さすぎる値(2文字)や大きすぎる値(8文字)との間のよいトレードオフです。タブを使うことはルールに準拠しつつ(右寄せタブを使うことにだけ注意してください)、エディタ上で自分の好みに合わせて表示を調整できることを意味します。red/redリポジトリ上の全てのRedのファイルはヘッダに以下のフィールドを含める必要があります。4ブロックか括弧を開いた後は、改行し、タブ1つ分インデントします。空のブロックはスペースを含みません。[]連続するブロックの間はスペースは不要です。world]しかし、ネストしたブロックの間にスペースを使うのは許されます。]小さいブロックを含む式では、通常同じ行で括弧を開いて閉じます。1][3]もし一行が長すぎる場合、ブロックは一段階のインデントで複数行にまたがって書きます。ブロックの引数が検知される前に評価されてしまいます)。最初のブロックが十分短く、同じ行が書くことが適切な場合は、後続のブロックのみを複数行に渡ってラップします。できるだけ短く意味を捉えた単語を選びます。一般的な単語をまずは検討します(そうではないケースとして、同じコンテキスト内でRedのソースコードに同じwordが使われている場合があります)。使い、使用する最適な単語を見つけてください。一文字や省略された単語は(省略された単語が一般的に使われている場合以外は)できるだけ避けるべきです。二文字の言葉は適切な一文字の単語が見つからなかったり、すでに使用されていて混乱を招く場合にのみ使うべきです。2文字より多い単語の変数名はレアケースでのみ使うべきです。できる限り一単語の変数使うことは、コードをトータルでずっとコンパクトにし、可読性を大きく向上させ、冗長性を低減させます。使うようにしますが、2、3語からなる名称が必要になることはしばしばあります。3文字を超えるwordはできるだけ避けるべきです。変数の命名規則は関数の名前にも適用されます。名詞か形容詞にクエスチョンマークを付けたものも許されます。型であることを示しますが、厳格なルールではありません。2語以上の単語の関数名を作る場合、動詞を最初に配置します。変数名と関数名が注意深く選択されている場合、コード自体がドキュメントのように機能し、コメントの必要性を軽減します。fill-blueにするべきです命名規則の例外はOSやRedではないサードパーティのAPIの名称の場合です。API固有の関数や構造体のフィールド名であることが分かりやすいように、オリジナルの名前を使うべきです。それは通常のRedやRed/Systemコードと、そのようなインポートされた名称を区別するのに役立ちます。全ての変数と関数の名称は基本的には小文字にします。大文字にするのは以下の様な場合です:名称が略語である場合。マクロ(Red/System)Red/Systemのマクロの名称を選択する時も同様の命名規則を適用します。マクロは一般的に名前には大文字を使い、他のコードと容易に区別できるようにします(擬似的な独自のデータ型の定義のように)一般的なコードと同じように見せたい、のような明確的な意図がない限り)。区切り、通常のコードとの差異が際立つようにします。全般的なルールはスペックブロックを1行に収めることです。ボディブロックは同じ行か複数行にまたがることができます。Red/Systemの場合、スペックブロックは長くなることが多いため、ほとんどの関数のスペックブロックは複数行にまたがります。そのため視覚的な一貫性の観点から、短いスペックブロックでも折り返すことがあります。1]スペックブロックが長すぎる場合、複数行にまたがるべきです。スペックブロックを折り返す場合、各型の定義は引数と同じ行にします。オプショナルな属性はのブロックは同じ行に記載します。それぞれのリファインメントは新しい行で始めます。引数が1つの場合、同じ行に書くか、インデントを1つ付けます(スペックブロック内の他のリファインメントと揃えてください)。/localリファインメントについては、ローカルのwordに型アノテーションを付けない場合、同じ行に書いてかまいません。スペックブロックを複数行にまたがって書く場合、可読性のため一連の引数のデータ型の定義を同じ行で揃えることを推奨します。行揃えは、コーディングスタイルを厳密に守るのであればタブで行ってください。robots][...]docstringは、スペックブロックが折り返しする場合のメインのドキュメント(関数自体の説明)は独立した行に記載します。引数とリファインメントのdocstringは対象と同じ行に記載します。関数は自動的にピリオドを補完します)。関数呼び出し関数の後の引数は同じ行に書きます。行が長くなりすぎる場合、引数は複数行(1つの引数につき1行)にまたがってインデント付きで記載します。argument5ネストが多く長い式については、それぞれの式の区切りを明示することが難しい場合があります。引数を伴うネストした関数呼び出しをグルーピングするために、丸括弧を使うことは許可されます(ただし、必須ではありません)。コメントRedのコードベースでは以下のようになっています。1行のコメントは57列目から始まります(平均的にはこれが最も適切な列数です。53列目を使います)。形式よりも、1行コメントを複数行使って記載します。一般的なルールとして、縦のスペースを取りすぎないように、コメントは対応するコードと同じ行に書きます。コメントがコードと分離している場合、新しい行に書いても問題ありません。形式は複数行文字列のために使います。このルールを遵守することで、以下のことが保証できます。使わずにすむため、可読性が向上します。