Go Code Review Comments
コメント
func や struct などのドキュメントのためのコメントは多少冗長であっても完全な文章でなくてはいけません。
このアプローチは godoc ドキュメントにするときにより効果を発揮します。
コメントは対象の名前で始まって、ピリオドで終わらなければいけない
外部に公開されるものにはコメントを書かなければならない
slice 宣言
s := [ ]string{ }よりもvar s [ ]stringのほうが良い
s := [ ]string{ }は0を返すが、var s [ ]stringはnilを返す。
状況に応じて使い分け
panicはなるべく使わない
エラー出力の文字列は大文字で始めない
その文字列は他のコンテキストで使われるケースがある
fmt.Errorf("Something bad")ではなくfmt.Errorf("something bad")
packageをリネームしてはいけない。
頭字語は一貫性がなければいけない
url => URL
ServerHttp => ServerHTTP
XmlHttpRequest => XMLHTTPRequest || xmlHTTPRequest
userId => userID
名前付き返り値は安易に利用しない
利用可能な場合
関数が同じ型の返り値を複数返したり、結果が文脈からはっきりとわかりにくい場合、名前付き戻り値は有効。
code:go
\\これよりも
func (f *Foo) Location() (float64, float64, error)
\\こっちの方が良い
func (f *Foo) Location() (lat, long float64, err error)
package名を含む識別子を使わない
引数にポインタ型を指定してはいけない
レシーバにポインタ型を渡すかどうか
レシーバの構造体の値を変更する場合はポインタ型
レシーバの構造体が大きい場合はポインタ型
それ以外はそのままの値
名前はできるだけ短く
宣言された箇所よりも離れた場所でその変数が使われるなら、より説明的な名前にするべき
メソッドレシーバ1〜2文字
for文の変数はiやrのように1文字
goroutineは終わるタイミングを明確にする
参照