web-dev-qa-db-ja.com

Golangでの「this」の使用

Golangが見つけたスタイルガイドに最も近いもの here 、Receiver Namesの下に次のように書かれています：

メソッドのレシーバーの名前は、そのアイデンティティーを反映したものでなければなりません。多くの場合、そのタイプの1文字または2文字の略語で十分です（「クライアント」の「c」または「cl」など）。 「me」、「this」、「self」などの一般的な名前は使用しないでください。関数ではなくメソッドに重点を置いたオブジェクト指向言語の典型的な識別子です。名前はメソッドの引数の名前ほど説明的である必要はありません。その役割は明白であり、文書化の目的を果たしません。

私は個人的に常に「this」を識別子として使用してきました。「this」は、関数を作成および編集するときに作業している対象の焦点だからです。それは正しいように聞こえ、そして（少なくとも私にとって）それは理にかなっています。

名前が説明的である必要がない場合、その役割は明白であり、それは記録目的ではないので、なぜ「これ」の使用が嫌われますか？

coding-stylenaminggolang
12
Adam

そのスタイルガイドの作者に確実に知るように依頼する必要がありますが、私が彼に少し同意する主な理由は次のとおりだと思いますGoの構造とメソッド間の接続は他の言語よりもはるかに緩いです。

本質的には、次のようなメソッドを作成するとします。

func (m *MultiShape) area() float64 {
  ...
}

これは、次のような関数を書くのとほとんど同じです。

func area(m *MultiShape) float64 {
  ...
}

唯一の違いは、関数/メソッドの呼び出し方法のわずかな構文の変更です。

他の言語では、this/self/whatever変数は通常、言語によって魔法のように提供されたり、プライベートメソッドに特別なアクセス権を持っているなどの特別なプロパティを持っています（Goにはプライベートフィールドがないことに注意してください） /メソッド）。 「レシーバー」はまだある程度「魔法のように」提供されていますが、通常の関数引数と非常に似ているため、間違いなく数えられません。

さらに、「従来の」OOP言語では、構造体/クラスのメソッドにはすべて構造体/クラス定義が付属しているため、外部からこれ以上追加することはできません。Goでは、私の知る限り誰でも（もちろん、自分のコードのスコープ内で）何にでもメソッドを追加できます。

私は自分のスタイルガイドを作成するのに十分なGoを記述していませんが、個人的には、受信する構造体と同じファイルで定義されたメソッドでthisを使用し、メソッドでいくつかの説明的なレシーバー名を使用します他のファイルから構造体にアタッチします。

11
Ixrec

私はこのスタイルガイドに確信が持てず、this、meまたはselfより優れているものはないと思います。 this、meまたはselfは、変数がコンテキスト構造体のインスタンスであることを非常に明確にするためです。小文字の構造体名の変数が悪い考えだと言っているのではなく、thisが非常に明確にする方法が好きです。

6
Qian Chen

これは、thisがコンパイラにとって実際のキーワードの意味を持っているJavaScriptの観点からですが、私の理解では、オブジェクトタイプの2文字の省略形で問題がなければ、それを使用するのは十分簡単です。代わりに。違いの理由は、徐々に深くなる非同期コードのかなり大きなブロックでは、「これ」、つまりレシーバーがより深いコンテキストにあるものを誤って解釈することが非常に簡単になる可能性があるためです。同じオブジェクトではない可能性もあります。

たとえばJavaScriptでは、制御モジュールがダイアログを起動し、onLoad関数をインラインで宣言する場合があります。しかし、その時点で、別のコーダーがthis内のonLoadを誤って解釈して、ダイアログではなく制御モジュールを参照するのは非常に簡単です。またはその逆。これは、コントロールがctrlとして、ダイアログがdgとして参照されている場合は回避できます。

0
Katana314