書かれたプログラムが、プログラミングにおける原則を遵守しているか否かを チェックしてください。

チェック対象については、 現在いるブランチの上で追加・編集され、リモートにアップロードされていないプログラムです。

原則

KISS

コードをシンプルに保つという原則 最優先事項を「単純性」「簡潔性」に置く。

• 新規記述
• 障害修正
• 機能拡張

を行う場合、複雑にならないようにシンプルに保つように作成する

「シンプルに保つ」とは

• 構成する各要素がシンプルであること
• 各要素が担う責務が最小限に抑えられていること
• 各要素同士の関連構造もシンプルであること

DRY

「コードのコピー&ペーストをしてはならない」という例えが用いられる 同じコードが複数の場所にあってはならないという原則

コードの今後の改善が発生した場合、同じ内容のコードが複数の位置に ハードコードされていた場合、コードリーディングやコード修正が困難になる それをコードの抽象化によって防ぐ。

ロジックであれば、処理のまとまりを命名し関数にすることによるモジュール化を行う。 データであれば、命名して定数を定義する

YAGNI

コードは必要最低限でなければならないという原則 「本当に必要になった時にこそ、そのコードを書く」という意味合いでもある。 先読みしてコードを書くと、結局利用されないかもしくは予測が外れることがほとんどであるため。 今、必要なものだけ、書きましょう。

PIE

コードの意図を明確に表現するように書かなければならないという原則 コードこそ、ソフトウェアの動作を「正確に」「完全に」知るための手がかりであるため。 結局のところ、どんなドキュメントよリもコード自体が最新の更新を如実に表しているため。 わかりやすいコードを書き、コード自体に意図を伝えさせるのがベストである。 そのため、「書きやすい」ではなく「読みやすい」コードを書く方が優先である。

SLAP

抽象化のレベルは統一するという原則 コードを書くとき、

• 高いレベルの抽象化概念（高水準）
• 低いレベルの抽象化概念（低水準）

を分離するようにする。その際、高低2階層ではなく、 機能の複雑さに応じて多階層に分離する。 そして、それら各々の層において、自分の層に所属する抽象レベルを揃える。 つまり、関数を抽象レベルに沿って分割していき、同じ関数に属するコードの抽象レベルを全て統一する。 抽象レベルが揃うことによって、綿密にコードが構成されるようになる 高水準から中水準の処理が本の目次のように、低水準の処理が本の本文内容のように読みやすくなる。

レベルが揃った関数に分割されていることが、コードの要約性と閲覧性を同時に満たすことになる。 関数一覧が目次として要約性を持ち、分割された関数は小さなコードの塊になり、閲覧性がよくなる。

そのためには、関数の構造化が必要。 処理を意図の伝わりやすい抽象化レベルが揃った小さなステップ群の関数に変換する それによって、各関数は自身より1段低いレベルの関数を呼び出す処理が中心になる。 このような他の関数を呼び出すコードで構成された関数を複合関数とすると、 これは極力小さくなくてはならない。 名前で意図を伝えるためであれば、処理が一行であっても関数にしても構わない。 複合関数の制約として、様々な抽象レベルの関数を呼ばず、必ず揃えたレベルの関数を呼ぶこと。