- エディター/IDEスタイリングの標準化
- コミット前の静的解析
- Ruby、Rails、RSpec
- データベースの移行
- ジャバスクリプト
- SCSS
- 行く
- シェルコマンド(Ruby)
- シェルスクリプト
- Markdown
- ドキュメント
- Python
- その他
スタイルガイド
エディター/IDEスタイリングの標準化
EditorConfigを使用して、ファイルがローカルに保存される前に、自動的に特定のスタイル基準を適用します。 ほとんどのエディタ/IDEは、.editorconfig
デフォルトで自動的に設定を .editorconfig
尊重.editorconfig
します。 エディタ/IDEが自動的にサポートしない場合は .editorconfig
、プラグインが存在するかどうかを調査することをお勧めします。 例えば、vim用のプラグインはこちらです。
コミット前の静的解析
ローカルでコミットする前に静的解析の違反がないか自動的にチェックするOvercommitをインストールすることを強くお勧めします。
GitLabのソースディレクトリで実行します:
make -C tooling/overcommit
そして、コミットが作成される前に、Overcommitはすべての変更されたファイルについてRuboCop(およびその他のチェック)の違反がないかどうかを自動的にチェックします。
CIによって同じエラーが検出されるのを待つ必要がないので、時間の節約になります。
オーバーコミットは、ルールセットに違反するコミットを防止するためのプレコミットフックに依存しています。この挙動をオーバーライドしたい場合は、ENV 変数OVERCOMMIT_DISABLE
を渡します。つまり、OVERCOMMIT_DISABLE=1 git rebase master
で rebase を実行し、Git フックを無効にします。
Ruby、Rails、RSpec
私たちのコードベースのスタイルはRuboCopによって定義され、強制されています。
bundle exec rubocop --parallel
。 CIでは、static-analysis
ジョブによって自動的にチェックされます。
まだ決定していない RuboCop のルールについては、慣用的な Ruby/Rails/RSpec を書くための一般的なガイドラインとして、Ruby スタイルガイド、Rails スタイルガイド、RSpec スタイルガイドに従いますが、レビュアー/メンテナーはスタイルについてあまり衒学的にならず、寛容であるべきです。
同様に、いくつかのRuboCopのルールは現在無効になっており、レビュアー/メンテナーは作成者にどちらかのスタイルを使うよう求めてはいけません。 これは自転車操業の余地を残してしまうので理想的な状況ではありません。理想的には、スタイルに関連した議論/ニットピッキング/レビューでの行き違いを避けるために、すべてのRuboCopルールを有効にすべきです。
さらに、改行専用のスタイルガイド、テスト専用のスタイルガイド、ベストプラクティスもあります。
新しいRuboCop警官の作成
一般的に、lintルールはプログラムによって実行される方が、前述のようなバイクシェッディングを減らすことができます。
そのため、コードベースでは新しいRuboCopルールを作成することを推奨しています。
複数のアプリケーションに適用できるような新しいcopを作成する場合は、GitLab Stylesgemに追加することをお勧めします。
データベースの移行
ジャバスクリプト
専用のJSスタイルガイドを参照してください。
SCSS
専用のSCSSスタイルガイドを参照してください。
行く
専用の囲碁基準とスタイルガイドラインを参照してください。
シェルコマンド(Ruby)
GitLabコードベースのシェルコマンド専用のガイドラインを参照してください。
シェルスクリプト
専用のシェルスクリプトの標準とスタイルガイドラインを参照してください。
Markdown
Ciro SantilliのMarkdownスタイルガイドに従っています。
ドキュメント
専用のドキュメント・スタイル・ガイドを参照してください。
Python
専用の Python開発ガイドラインを参照してください。
その他
コードは米国英語で記述してください。