Effective Go 翻訳 ~ Names

Effective Go 翻訳 – Names

Names are as important in Go as in any other language. They even have semantic effect: the visibility of a name outside a package is determined by whether its first character is upper case. It’s therefore worth spending a little time talking about naming conventions in Go programs.

https://golang.org/doc/effective_go#names

Goにおける名前は他の言語と同じくらい重要です。最初の文字が大文字かどうかによってパッケージの外から参照できるか決定されるように、名前は人にとって意味を成す効果を持ちます。そのためGoプログラムでネーミングの慣習について時間を使う価値があります。

Package names

When a package is imported, the package name becomes an accessor for the contents. After

https://golang.org/doc/effective_go#names

パッケージがインポートされる時、パッケージ名はコンテンツへのアクセサーとなります。

import "bytes"

the importing package can talk about bytes.Buffer. It’s helpful if everyone using the package can use the same name to refer to its contents, which implies that the package name should be good: short, concise, evocative. By convention, packages are given lower case, single-word names; there should be no need for underscores or mixedCaps. Err on the side of brevity, since everyone using your package will be typing that name. And don’t worry about collisions a priori. The package name is only the default name for imports; it need not be unique across all source code, and in the rare case of a collision the importing package can choose a different name to use locally. In any case, confusion is rare because the file name in the import determines just which package is being used.

https://golang.org/doc/effective_go#names

パッケージインポートimport "bytes"の後、bytes.Bufferについて話すことができます。パッケージを使用するすべての人が同じ名前で内容を参照できると便利です。それは、パッケージ名は短く、簡潔、連想させるような良い名前であるべきであることを暗に意味します。慣習として、パッケージは小文字で人単語の名前で与えられます。アンダースコアやミックスキャプスは必要とすべきではありません。パッケージを使用するすべての人が名前をタイピングするため、簡潔にし過ぎるくらい簡潔にしてください。そして、衝突について事前に心配する必要はありません。パッケージ名はインポートのためのデフォルト名のみです。それは、すべてのソースコードに渡ってユニークである必要はなく、衝突というレアケースではインポートするパッケージは使用するローカルで違う名前を選ぶことができます。いずれにしても、インポート時のファイル名は使用されているどのパッケージかを決めるため、混乱することは稀です。

Another convention is that the package name is the base name of its source directory; the package in src/encoding/base64 is imported as "encoding/base64" but has name base64, not encoding_base64 and not encodingBase64.

https://golang.org/doc/effective_go#names

別の慣習として、パッケージ名はソースディレクトリのベース名であるという慣習があります。src/encoding/base64内のパッケージは"encoding/base64"としてインポートされますが、base64という名前であり、encoding_base64でもencodingBase64でもありません。

The importer of a package will use the name to refer to its contents, so exported names in the package can use that fact to avoid repetition. (Don’t use the import . notation, which can simplify tests that must run outside the package they are testing, but should otherwise be avoided.) For instance, the buffered reader type in the bufio package is called Reader, not BufReader, because users see it as bufio.Reader, which is a clear, concise name. Moreover, because imported entities are always addressed with their package name, bufio.Reader does not conflict with io.Reader. Similarly, the function to make new instances of ring.Ring—which is the definition of a constructor in Go—would normally be called NewRing, but since Ring is the only type exported by the package, and since the package is called ring, it’s called just New, which clients of the package see as ring.New. Use the package structure to help you choose good names.

https://golang.org/doc/effective_go#names

パッケージのインポーターはその名前を使ってコンテンツを参照するため、パッケージ内のエクスポートされる名前はその事実を利用して繰り返しを避けることができます。（import .表記を使ってはいけません。それは、テスト対象のパッケージの外で実行されなければならないテストを簡単にすることができますが、それ以外の場合は避けるべきです。）例えば、bufioパッケージにおけるbuffered readerタイプは、ユーザはbufio.Readerとしてそれを見るため、BufReaderではなく、Readerと呼ばれ、これは明瞭で簡潔な名前です。さらに、インポートされたエンティティはいつもそれらのパッケージ名で表示されるため、bufio.Readerはio.Readerと衝突しません。同様に、ring.Ringの新しいインスタンスを生成する関数（Goのコンストラクタの定義）は通常NewRingと呼ばれますが、Ringはパッケージによってエクスポートされる唯一のタイプであり、パッケージはringと呼ばれるため、それはNewと呼ばれ、パッケージのクライアントはring.Newとして見ます。パッケージ構造を使用することはあなたが良い名前を選ぶことを助けます。

Another short example is once.Do; once.Do(setup) reads well and would not be improved by writing once.DoOrWaitUntilDone(setup). Long names don’t automatically make things more readable. A helpful doc comment can often be more valuable than an extra long name.

https://golang.org/doc/effective_go#names

once.Doは別の短い例です。once.Do(setup)は読みやすく、once.DoOrWaitUntilDone(setup)と書くことで改善されないでしょう。長い名前は自動的に物事をより読みやすくしません。役に立つdocコメントは余分に長い名前よりもしばしば価値があります。

Getters

Go doesn’t provide automatic support for getters and setters. There’s nothing wrong with providing getters and setters yourself, and it’s often appropriate to do so, but it’s neither idiomatic nor necessary to put Get into the getter’s name. If you have a field called owner (lower case, unexported), the getter method should be called Owner (upper case, exported), not GetOwner. The use of upper-case names for export provides the hook to discriminate the field from the method. A setter function, if needed, will likely be called SetOwner. Both names read well in practice:

https://golang.org/doc/effective_go#names

Goはゲッターとセッターの自動的なサポートを提供しません。ゲッターとセッターを自分で提供することは全く悪いことではなく、そのようにすることはしばしば適切ですが、Getをゲッターの名前に入れることは慣用的でも必要もありません。もしowner（小文字、エクスポートされていない）と呼ばれるフィールドを持っていたとして、ゲッターメソッドはGetOwnerではなく、Owner（大文字、エクスポートされている）と呼ばれるべきです。エクスポートとしてアッパーケースの名前を利用することはメソッドからフィールドを識別するフックを提供します。もし必要なら、セッター関数はSetOwnerと呼ばれるでしょう。実際に両方の名前は読みやすいです。

owner := obj.Owner()
if owner != user {
    obj.SetOwner(user)
}

Interface names

By convention, one-method interfaces are named by the method name plus an -er suffix or similar modification to construct an agent noun: Reader, Writer, Formatter, CloseNotifier etc.

https://golang.org/doc/effective_go#names

慣習として、一つのメソッドを持つインターフェイスはメソッド名に-erサフィックスをプラスした名前や、Reader, Writer, Formatter, CloseNotifierなどの名詞を構築するための類似した変更によって名前づけられます。

There are a number of such names and it’s productive to honor them and the function names they capture. Read, Write, Close, Flush, String and so on have canonical signatures and meanings. To avoid confusion, don’t give your method one of those names unless it has the same signature and meaning. Conversely, if your type implements a method with the same meaning as a method on a well-known type, give it the same name and signature; call your string-converter method String not ToString.

https://golang.org/doc/effective_go#names

そのような名前は多くあり、それらの名前とそれらがキャプチャするメソッド名を尊重することは生産的です。Read, Write, Close, Flush, Stringなどは正規の署名と意味があります。混乱を避けるため、同じ署名や意味を持たない限り、あなたのメソッドにそれらの名前の一つを与えないようにしてください。反対に、もしあなたのtypeがよく知られるtypeのメソッドと同じ意味を持つメソッドを実装しているならば、そのメソッドに同じ名前と署名を与える必要があります。あなたのstring-converterメソッドをToStringではなく、Stringと呼んでください。

MixedCaps

Finally, the convention in Go is to use MixedCaps or mixedCaps rather than underscores to write multiword names.

https://golang.org/doc/effective_go#names

最後に、Goの慣習では、複数単語から成る名前はアンダースコアで書くよりMixedCapsやmixedCapsを利用します。

【自分用】文法/熟語メモ

therefore（それゆえに、そのため、従って）

硬いので口語では使わない。

be worth ~ing（〜する価値がある）

There is nothing wrong with ~（〜に全く問題がない）

neither A nor B（AでもBでもない）

in practice（実際には）

put A into B（AをBに入れる、AをBの状態にする、AをBに翻訳する、AをBで表現する）

a number of ~（たくさんの〜）

unless ~（〜でない限り、〜しない限り）

【自分用】単語メモ

参考

neither A nor B の使い方
put A into B
in practice
unless の使い方