新しいプログラミング言語を学ぶときは、入門書などで基本的な文法を一通り理解した後などのタイミングでコードスタイルガイド(いわゆるコーディング規約)を読むととても勉強になることが多いです。最近は、知見のある会社がGithub上で「我が社のスタイルガイドはこれです！」と公開しているものが多く、とても参考になります。今回はスタイルガイドを読むのがなぜいいのかを書いていきます。
スタイルガイドを読むのはいつ？
プログラミングを学ぼうとするときには、何らかの書籍やサイトの情報を参考にして、手を動かすことが多いと思います。
プログラミングに関する書籍はざっくりいうと以下のように分類できます。(私見入りまくりですが。）
- とりあえず動くものを作ってみようというチュートリアル本(言語の説明は最低限にとどまる）
- 言語の機能や構文をだいたい網羅して説明している本
- 言語の仕様などを深く掘り下げて解説する本（Javascriptでいうサイ本、Rubyでいうハチドリ本）
- よりよい設計、パフォーマンス改善などの問題を改善するためのベスト・プラクティスを解説する本
今、友人と「詳解Swift」という書籍を読んでいるのですが、この書籍は上の2にあたります。
この手の書籍では、言語でできることを説明しているので、実際に使うとコードがメンテナンスしにくくなる機能だったり、コードを書いた人の意図がコードに表れにくいために他の人が理解しづらくなる = チーム開発には向かないような式・構文も紹介されていたりします。2や3にあたる本は、実用的かというよりも、何ができるかを解説するのが目的にした書籍であるため、仕方がありません。
学んだ言語で基本的なことができるようになった -> よし！何か作るぞとなり、学んだことを全て注いでコードを書くと（まあ、好きに書けばいいんですけどね）、だんだんとコードが複雑になってきて、どう書くのがいいんだろう？といった疑問がでてきたりします。しかし、上の4にあたる書籍を読む必要性に駆られるほど経験があるわけでもない。こういうタイミングがスタイルガイドの読み時の1つです。
読むと何がいいのか？
- 読みやすいコードを書けるようになる
- 1人で開発していたとしても読みやすくしておくことは大事です。将来の自分から見ると過去の自分が書いたコードは別人のコードに見えます
- 複数の実装の選択肢がある場合、よりよい選択肢を知ることができる
- 例えば、Github社のSwiftのスタイルガイドでは、classではなくできるだけstructを使いましょうといったことが理由と一緒に解説されています。github/swift-style-guide
- パフォーマンスの観点でのよりよい実装方法を知ることができる
- 文字列結合で余計なオブジェクトを生成しないようにするのは、どの言語でも共通していえることですね。
- スタイルガイドを採用しているチームの開発に参加する場合などに基準を1つもっているとスムーズに入れる
- オープンソースのコードなども有名なスタイルガイドに準拠している（または近い）ことが多いので、他の人のコードを読みやすくなる
どういうスタイルガイドを読めばいいか？
自分がいくつかスタイルガイドを読んだ中でいいなと感じたものをまとめます。
- bad, goodの両方のサンプルコードが掲載されている
結論だけ述べているものよりも、推奨されない例との比較があるとスタイルガイド自体が読みやすいです。(スタイルガイドのスタイルを統一してもらいたいくらい）
# bad
def some_method()
# body omitted
end
# good
def some_method
# body omitted
end- 理由が解説されている
正直、この一点に尽きます。
なぜ、このスタイルを推奨しているのかというWhyを解説しているスタイルガイドはとても勉強になります。
逆にHowだけ記載していてWhyを記載していない場合は、読んでてストレスがたまるので他にいいガイドがないか探してみたほうがいいです。
スタイルガイドのサンプル
この記事を書くにあたっていくつかスタイルガイドを調べたので、参考リンクを貼っておきます。
他にもたくさんあるので探してみてください。
- ruby
- rails
- swift
- Haskell
