Go Conference 2014 Autumnレポート

鵜飼文敏氏「Goに入ってはGoに従え」可読性のあるコードにするために~Go Conference 2014 Autumn基調講演2人目

この記事を読むのに必要な時間:およそ 10 分

コメント

レビューにおいて,コメントに対する指摘を行うことが多いと同氏は述べていました。そして,よく指摘する項目として

を挙げていました。

上記の3つの項目を満たす正しいコメントは以下のようになるそうです。

// Package math provides basic constants and mathematical functions.
package math

// A Request represents a request to run a command.
type Request struct { ..

// Encode writes the JSON encoding of req to w.
func Encode(w io.Writer, req *Request) {

このように書いておくと,grepもしやすくgodocで確認した場合も見やすくなるとのことでした。また,同氏はgodoc-httpオプションをつけてWebブラウザで確認することもできると述べていました。

$ godoc bytes Buffer

$ godoc -http=:6060  # http://localhost:6060/pkg

同氏は,コメントがわかりにくい/うまく書けないときは,APIの設計を考え直したほうが良いと主張していました。また,上記のようにコメントを書いてgodocで確認することで,APIの設計が問題ないか考えることができると述べていました。

APIデザイン

同氏は,APIをデザインするうえで最も大切なことは適切な名前のパッケージを作ることであると述べていました。たとえば,よくutilというパッケージを作ってそこにいろいろなものを入れてしまいがちだが,もっと細かくパッケージを分けるか,もっと大きなパッケージの一部として定義するかのどちらかにするべきだと指摘していました。

同氏はAPIをシンプルにするためのルールとして以下の項目を挙げていました。

  • 複数の戻り値を使えるので,出力変数としてポインタは使わない。
  • スライス,マップ,チャネル,インターフェースへのポインタは使わない。
  • エラーはerrorで返す(panicは使わない)⁠
  • 一般的なインターフェース(fmt.Stringerio.Readerなど)に挙動が適合する場合は合わせる。
  • 引数などはインターフェースのほうが組み合わせやすいしテストもしやすい。
    • 例:ファイルから読む関数などは*os.Fileよりio.Readerなどが引数のほうが良い。
  • 非同期APIより同期API(パッケージを越えてチャネルあまり使わない)⁠
  • 非同期にするにはAPIを使う側がゴルーチンとチャネルで制御する。

まとめ

同氏は,コードはコミュニケーションであると述べていました。 そのためには明瞭に表現することが大切で,以下のことを守る必要があると述べていました。

  • 適切な名前を選ぶ
  • シンプルなAPIを提供する
  • わかりやすいドキュメントを書く
  • 複雑にしすぎない

この基調講演では,どうやったらGo言語らしく書けるのかということを具体例とともに説明されていました。聴講した多くの方にとって,Go言語のコードを書くことはあってもレビューされる/する機会というのはまだ少ないと思います。そのため,この講演は,可読性のあるコードにするために,どういった観点でレビューをされるのか知る貴重な機会になったかと思います。

著者プロフィール

上田拓也(うえだたくや)

KLab(株)所属。Go Conference 2014 Autumnスタッフ。

業務ではJavaScript,Luaなどを扱っている。

大学時代にGo言語に出会い,それ以来Go言語にのめり込む。

時間があると,Go言語の勉強会に参加している。

Go言語のマスコットのGopherの絵を描くのも好き。

Twitter:@tenntenn

コメント

コメントの記入