こんにちは！ Product Develop Division Renosyチームの佐藤です。 Renosyチームでは、毎週勉強会を実施しています。 せっかくなので、勉強会の内容をこのブログにアウトプットしていきたいと思います。
テーマ：
チーム内のstyleguideを作ろう！
Renosyチームは、結成当初は3人のエンジニア体制でしたが、現在10名まで増え、そのバックボーンも新卒からベテラン中途まで様々です。 そのため、コードの品質やチーム開発のためにstyleguideを作った方がいいなと感じることが増えてきました。 しかし、白紙な状態からつくるのも難しいため、まず最初はCookpadさんのstyleguideを参考にさせていただこうと考えました。 そこで、勉強会の時間を使って、Cookpadさんのstyleguideを読みあって、議論を深め、自分たちのstyleguideへエンハンスしていきたいと考えています。
以下、話題になった内容です。
・キーワード引数
保守の効率を上げたりするのに役立つため、積極的に利用しようという結論になりました。 しかし、Rubyの中では比較的新しい仕様のため、利用経験が少ないエンジニアが多かったので、改めてこれを題材に勉強会をしようという話になりました。
・シンボルリテラル
シンボルリテラル(%i)などは、可読性や一貫性の観点から使用しないという結論になりました。
・文字エンコーディングとマジックコメント
そもそもutf8以外のエンコーディングやマジックコメントの存在を意識したことがないエンジニアが多いことがわかりました（！） 私は、ruby1.8系の頃から使っているので思わず時代を感じてしまいました・・。
・文字列
式展開しない場合の文字列は、シングルクォーテーション''、する場合はダブルクォーテーション""を利用することとしました。これは、コードレビュワーが、「ダブルクォーテーションを使っているから、ここでは文字列展開するんだな」という観点でコードを読めるためです。
・正規表現
基本的に他人が書いた正規表現を読み解くのは難しいの原則に立ち、意図をコメントを書くようにする、というルールにしました。
・配列
他の言語をやっているエンジニアが多いということから、最後のカンマは消す（最後の要素が足りているかがわからないため）というルールにしました。
・範囲リテラルの配列変換
初学者に難しいため、あえてわかりやすさを重視して、Range#to_aを選択しました。
・ハッシュ
可読性確保のため、配列と異なり、積極的に改行を推奨することにしました。
・演算子
議論の延長で、a == 0 を a.zero? と書いたり、 a > 0 を a.positive? と書いたりすることは、数値リテラルを減らす利点はあるもののぱっと見わからなくなるので、直感的に把握できる数字比較にしようという結論になりました。
・代入式
ライブラリなどが配列を返す際は利用するが、自分でメソッドを作成する際は、ハッシュを返すようにしようという結論になりました。
今日はここで時間切れとなりました。 次回に続きます！
