開発ルール
githubの運用ルール
とにかく、レビュアーフレンドリーなPR、ISSUEを心がける
・githubのPRの説明欄に、必ずISSUEのURLを貼り付けること
・gitにコミットするときは、 #176 のようにISSUE番号をコミットメッセージにつけること。
そうするとgithubの仕様的に、ISSUEにコミットが自動で紐づいて、対象のコミットが閲覧できるようになる。
・可能な限り、エビデンスを貼ること。エビデンスが貼れないときは、コミットorPRのURLを貼ること。
注意点
存在しないメアドへメール送信しないこと
メール送信処理を開発する際、admin@abc.com のようなダミーメールアドレスへ送信する処理を書かないこと。
AWSのSESを使っている場合、バウンスしてメールサービスが使えなくなるリスクがあるため。
変数名の命名ルール
コーディングルールを確認する
PHPだったらPSRとか、言語や現場のルールを確認すること
キャメル or スネークケースを意識する
isStringなのか、is_stringなのか、ルールを決める。
言語や現場のルールを確認せよ。
単数・複数を意識する
articles # 複数だということが一目でわかる article
# NG article = new Array();
# OK articles = new Array();
無意味なワードはつけない
# NG article_list article_items
↓シンプルにこれで良くね？
# OK articles
booleanは、is_ has_ などをつける
# NG string = true; # OK is_string = true;
コメントのルール
不要なコメントは消す
このコードあとで使うかもーと思ってもコミットしないこと。
コミットは綺麗に。
インデントのルール
オートインデントは修正行のみ有効にすること
エディタの機能でファイル全体オートインデントをしてしまうと、
変更差分が多く出過ぎるので、
基本は、自分が変更した行だけに留めること。
そのほうがレビューもしやすいし、
後からバグが起きた時などに、
差分を追うときに便利だからです
エディタの機能で、自分が変更した行だけインデントを有効にする設定があるかと。
Rubymineの場合は、こんな感じです
https://footprints.link/articles/ja/n-machida/reformat-code-when-file-saved-in-intellij-idea
あまりにコードが汚くて
リファクタしたい場合は、
それ用のISSUEを作ってやるのがベターです