Kyoto.go remote #9 Reading uber-go/guide お題
事前に読めるひとは読んでおく(努力目標)
気になったこと/わからなかったこと/疑問に思ったこと
iota enumでゼロ値を避ける目的 → 初期化漏れで意図しない値になる
時間操作の落とし穴
うるう年、うるう秒、サマータイムなどの影響を考慮しないといけない
timeパッケージ使おう
time.Timeの比較
start <= now相当の記述がstart.Before(now) || start.Equal(now)になるのは冗長では?
!start.After(now)と書き換えるのはどうか
コードコメントつけたい
別の方に変換して比較する方法もあった気がします(uji)
time.Duration
time.Durationという型がついていると、値が秒なのかミリ秒なのかという混乱を防げる
実体はint64型
RubyDateっていう形式があるのかーyebis0942.icon
オリジナル版には「timeパッケージはうるう秒を無視するケースがあるから一応気をつけてね」という記述がある
Although this tends to not be a problem in practice, keep in mind that the "time" package does not support parsing timestamps with leap seconds (8728), nor does it account for leap seconds in calculations (15190).
エラー処理
var ErrCouldNotOpen = errors.New("could not open")みたいにパッケージがエラーを外部公開してくれているとテスト書きやすい
テスト書くのがつらくなる要因
動的に変わるエラーメッセージのアサーション
他のエラーを内包したエラーのアサーション
自前のエラー型を公開する場合、それも公開APIの一種です。気をつけましょう。 代わりにエラー型と一致しているかを判定する関数を公開するほうがよいでしょう。
エラー型を公開すると他のところで使われてしまうかもしれない=公開API
エラーそのものより判定する関数を公開したほうが外部に公開する情報が減ってよさそう
「そこまで対策する必要あるのか?まあ対策したほうがいいのかな」
エラーメッセージの書き方
できるだけ簡潔に書くことが勧められている
"failed to"とかいらない
言語によってポリシーが違いそう
ログを読みやすくするのはアプリケーションのロギング処理の役割
参考: Goには「エラーメッセージの文頭を大文字にしない」みたいな慣例がある
Error strings should not be capitalized (unless beginning with proper nouns or acronyms) or end with punctuation, since they are usually printed following other context.
いつpanicするのか
エラーで表現できるところではエラーを使う
プログラムの継続が困難なときだけpanicを使う
初期化に失敗したときとか
テストが失敗したことを示すためにはpanicではなくて t.Fatal や t.FailNow を使うようにしましょう。
そこでpanic使いたくなることある…?
確認したいこと
次回やりたいこと