• エディター/IDEスタイル標準化
• Lefthook によるプリプッシュ静的解析
  • オーバーコミットのアンインストール
  • Lefthookのインストール
  • Lefthook の設定
  • レフトフック自動修正ファイル
  • 一時的に lefthook を無効にします
  • Lefthook フックを手動で実行します。
  • タグごとのLefthookチェックをスキップ
  • 特定のLefthookチェックをスキップまたは有効にします。
• データベースのマイグレーション
• ジャバスクリプト
• SCSS
• Ruby
• Go
• シェルコマンド (Ruby)
• シェルスクリプト
• Markdown
• ドキュメント
  • グッドプラクティスのためのガイドライン
• Python
• その他

開発者向けスタイルガイド

エディター/IDEスタイル標準化

EditorConfigを使用して、ファイルがローカルに保存される前に特定のスタイル標準を自動的に適用します。エディタやIDEによっては、デフォルトで自動的に.editorconfig 。

エディターやIDEが自動的に.editorconfigをサポートしない場合、プラグインが存在しないか調査することをお勧めします。例えば、vim用のプラグインがあります。

Lefthook によるプリプッシュ静的解析

LefthookはGitフックマネージャで、Gitのコミットやプッシュの前にカスタムロジックを実行することができます。GitLabにはLefthookの設定(lefthook.yml)が付属していますが、インストールする必要があります。

lefthook.yml にチェックが入っていますが、Lefthookがインストールされるまでは無視されます。

オーバーコミットのアンインストール

Lefthookの前にOvercommitを使用していましたので、overcommit --uninstall でアンインストールしてください。

Lefthookのインストール

1. lefthookのインストール方法はさまざまです。グローバルにインストールせず (たとえば Homebrew やパッケージマネージャ経由で)、GitLab プロジェクトだけで使いたい場合は、Ruby gem をインストールします：

   bundle install
   

2. Lefthook manage Git hooks をインストールします：

   # If installed globally
   lefthook install
   # Or if installed via ruby gem
   bundle exec lefthook install
   

3. Lefthookpre-push Gitフックを実行して、Lefthookが動作していることをテストします：

   # If installed globally
   lefthook run pre-push
   # Or if installed via ruby gem
   bundle exec lefthook run pre-push
   

Lefthook のバージョンと実行可能なコマンドのリストが出力されるはずです。

Lefthook の設定

レフトフックは以下の組み合わせで設定します：

• lefthook.yml のプロジェクト設定。
• 任意のローカル設定。

レフトフック自動修正ファイル

自動修正機能を持つすべてのリンターを実行するために、カスタム lefthook ターゲットを用意しています。

# If installed globally
lefthook run auto-fix
# Or if installed via ruby gem
bundle exec lefthook run auto-fix

一時的に lefthook を無効にします

一時的に Lefthook を無効にするには、環境変数LEFTHOOK を0 に設定します。インスタンスンス：

LEFTHOOK=0 git push ...

Lefthook フックを手動で実行します。

pre-push Gitフックを実行するには、次のようにします：

bundle exec lefthook run pre-push

詳しくはLefthook のドキュメントをご覧ください。

タグごとのLefthookチェックをスキップ

プッシュ時にタグに基づくいくつかのチェックをスキップするには、LEFTHOOK_EXCLUDE 環境変数を設定します。インスタンスンス

LEFTHOOK_EXCLUDE=frontend,documentation git push ...

別の方法として、このような構造でlefthook-local.yml を作成することもできます：

pre-push:
  exclude_tags:
    - frontend
    - documentation

詳しくはLefthook のドキュメントをご覧ください。

特定のLefthookチェックをスキップまたは有効にします。

プッシュ時にその名前に基づいてチェックをスキップまたは有効にするには、そのフックのlefthook-local.yml セクションにskip: true またはskip: false を追加します。例えば、locale/gitlab.potのイシューを検出するために gettext チェックを有効にしたいとします：

pre-push:
  commands:
    gettext:
      skip: false

詳しくはLefthook documentation Skipping commands セクションをご覧ください。

データベースのマイグレーション

専用のデータベースマイグレーションスタイルガイドを参照してください。

ジャバスクリプト

専用のJSスタイルガイドを参照してください。

SCSS

専用のSCSSスタイルガイドを参照してください。

Ruby

専用のRubyスタイルガイドを参照してください。

Go

専用のGo標準とスタイルガイドラインを参照してください。

シェルコマンド (Ruby)

GitLabコードベースのシェルコマンド専用のガイドラインを参照してください。

シェルスクリプト

専用のShellスクリプトの標準とスタイルのガイドラインを参照してください。

Markdown

Ciro SantilliのMarkdownスタイルガイドに従っています。

ドキュメント

専用のドキュメンテーションスタイルガイドをご覧ください。

グッドプラクティスのためのガイドライン

グッドプラクティスの例は、避けるべきプラクティスの例と比較しながら、推奨されるコードの書き方を示しています。これらの例は、Bad（悪い）かGood（良い）かのラベルが付けられています。GitLabの開発者向けガイドラインでは、事例を紹介するときは、まずBad、次にGoodの戦略に従うことを推奨しています。まずBadの例（どのようにすればよいのか、多くの場合まだ動いているコードです）を示し、次にGoodの例を使ってどのようにすればよいのかを示します。これは通常、同じコードの改善例です。

例を提示するときは、以下のガイドラインを考慮してください：

• まず「悪い例」を挙げ、次に「良い例」を挙げます。
• 悪いケースと良いケースが1つずつしか与えられない場合は、同じコードブロックを使います。
• 悪い事例と良い事例が複数ある場合は、それぞれのコードブロックを分けてください。多くの例が提示されている場合、明確に分けることで、読者は良い部分に直接行くことができます。なぜそれが悪い習慣なのかについて、説明（例えばコメントやリソースへのリンク）を加えることを検討してください。
• ベターケースとベストケースは、グッドケースのコードブロックの一部と考えることができます。同じコードブロックの中で、それぞれの前にコメントを付けましょう:# Better と# Best。

Bad-Then-GoodのアプローチはGitLabの開発ガイドラインでは受け入れられますが、ユーザードキュメントでは使わないでください。ユーザー・ドキュメントでは、DoとDon’tを使い分けましょう。例としては、Pajamas DesignSystemをご覧ください。

Python

専用のPython開発ガイドラインを参照してください。

その他

コードは米国英語で記述してください。