Diary

@ssig33

03 Jun 2017 Sat 13:07

Go 最初は br だの err だの i だのそんな変数名のつけかた頭おかしいやろみたいな気持ちになるんだけど気付けばまあ自分もなんの疑問もなく

 func chkErr(err, error){
}

とかなんとか書くようになっているのであった。関数の解決する問題の範囲を極限まで狭くしろとかなんとかまあ理屈は分かるんだけど、我々は残念ながら理屈だけの世界で生きているわけではないから最終的に人間は死滅していくのであった。人間は死ぬが故に非合理、これだけは忘れてはいかんと思う。

それからわりとありがちなのが

if err != nil {
  return result, nil
} else {
  return nil, err
}

みたいなことをしたいというやつ。 nil も返せるようにするためには成功時の結果をポインタで返せるようにしとかないといけないから、そうした事情もあって気付けばなんでもかんでもポインタで返すようになって、別にポインタにしなくていいものも速攻ポインタにする病みたいのに罹患するようになる。僕自身注意しないとこれをやってしまうし、ライブラリのコードを読んでもわりと多くの人がポインタ太郎になっている。

実際には return するものは関数の最初で初期化しておいて、処理が失敗してエラーになればまあエラーになったときの状態を返せばいいのであろう。関数を利用する側が err が nil でなければその結果の側については捨てればいいだけなので。

でもなんだかんだでいろいろな事情があって return するものを初期化する位置が後ろのほうにズレていって nil も返したいんですが〜みたいになる。やはりこれも人間は死ぬが故に非合理という話である、そこでちゃんと関数の設計をまともにして直す暇があればとりあえずプロダクトを動く状態に持っていってしまいたくなる。