理念

このリストには、プロジェクトが守るべき基本的な考え方が含まれています。このリストは網羅的なものではありません。いくつかは明白なものですが、あえて記載されています。

プロジェクト管理

明確な見通しを設定する。 プロジェクトの意図と決定事項を事前に十分に周知します。予期せぬことは何も起こらないようにするべきです。
決定事項を明確に伝える。 チームは、プライベートチャンネルを使って選択肢を評価し、決定を下すことがあります。チームはGitHub discussionsやDiscordのようなパブリックチャンネルを使用して議論を行おうとしますが、通常の企業ではしばしばプライベートなチャンネルで議論してしまいがちです。プライベートチャンネルで決定が行われた場合、チームはこれらの決定をパブリックチャンネルを使用して伝える必要があります。

技術的なこと

エラーは、可能な限り修正の提案やヒントを示すべきです。 無関係で役に立たないメッセージが表示されないように、使用状況によって補足やフィルタリングがされるべきです。
ユニークで具体的なエラーメッセージ。 一般的なエラーメッセージは避けるべきです。これにより、ユーザーは何が間違っていたのかを理解しやすくなり、メンテナーは具体的な呼び出し箇所とデバッグに必要な情報を得ることができます。
APIを最適化する。 すべてのオプションとフラグの必要性を問いかけてください。それらは本当に必要ですか？組み合わせることはできませんか？どうしたらコードの分岐を減らすことができますか？
専門用語を控える。 ユーザーが特定の専門用語を理解しているとは考えないでください。専門家と初心者の両方に正確な意味を提供するよう努めてください。例えば、パーサーのエラーを出す際に”token”という用語の代わりに”character”を使用するなどです。
コマンドやフラグの命名には冗長性を持たせる。 不必要で紛らわしい略語は使用しないでください。
包括的な用語を使用する。 性別にとらわれない代名詞を使用してください。障害者の差別や無神経と思われる用語を使用しないでください。
汎用的なクライアント向けに構築する。 ターミナルがANSIコードを使用した出力のみを処理するとは限らないということを前提にしてください。 IDE、ブラウザ、その他の環境での閲覧に適した抽象化を使用してください。
ターミナルの出力は明確であるべきです。 ターミナルの出力を設計する際には、色のような書式だけに頼らないでください。常に書式、記号、スペーシングの組み合わせを使用してください。もし全てのANSIコードが取り除かれても、全ての出力が理解できるようにしてください。