- PR -

現在のインスタンスを参照するthisキーワード、付ける? or 付けない?

投票結果総投票数:259
付ける 99 38.22%
付けない 66 25.48%
付けたり付けなかったり 94 36.29%
  • 投票は恣意的に行われます。統計的な調査と異なり、投票データの正確性や標本の代表性は保証されません。
  • 投票結果の正当性や公平性について、@ITは一切保証も関与もいたしません。
投稿者投稿内容
未記入
会議室デビュー日: 2007/07/10
投稿数: 1
投稿日時: 2007-07-10 01:53
個人的には、必要ならつければいいかなと思ってます。

多くの事例を見たわけではないので、感覚なのですが、、

thisをつけないとインスタンス変数かどうかわかりにくいというのは、
バッドスメルな感じがします。

本当は、エディタがそれを識別して色を付けてくれれば良いんですけどね。

coasm
大ベテラン
会議室デビュー日: 2001/11/26
投稿数: 237
投稿日時: 2007-07-10 02:29
上手く説明できないのですが、いちいち this を付けるというのは、
オブジェクト指向の本質に根底から反しているように感じます。
せっかく抽象度の高いレベルで思考していたのを実装レベルまで引きずり落とす愚行、ではないかと。

私がthisを使うのは、
(1) 各フィールドと一対一対応するパラメータを持ったコンストラクタ。
パラメータ名とフィールド名を同じにするので、thisを付けて区別する。
(2) 比較や代入を行うメソッド。
ほぼ対等な2つのインスタンスが関与するので、this と that で参照する。
だけです。

C++なら、(2)のような例は メソッドではなくて2引数のfriend関数にした方が気持ちいいけど。
ぶさいくろう
ぬし
会議室デビュー日: 2005/11/22
投稿数: 1232
お住まい・勤務地: 川崎市(は俺も含めてロクな人間が住んでないよw)
投稿日時: 2007-07-10 09:11
いかにもthisを付けるやつが構造化すらできてないと決め付けている言い方をしているやつがいるが・・・
こりゃ不毛な議論を招くもとであると最初にいっておこう。
(この段階でだが)自分視点でしか意見を書けていないと非常に見苦しい。

しかし少し前にthisつけない派の理由にようやくそれらしい主張がでてきた。
「すべてにつけると目立たせるべきものが目立てない」というね。

これは期待age。

[ メッセージ編集済み 編集者: ぶさいくろう 編集日時 2007-07-10 09:16 ]
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2007-07-10 10:10
引用:

まりもさんの書き込み (2007-07-10 00:02) より:

メソッド内変数か、インスタンスフィールドか、静的フィールドか、常に区別しておくのが大切というのは確かにそうです。が、それは、ソースを読むたびに必ず強く頭に置かねばならないものでしょうか?

引用:

実際のところ、インスタンスフィールドと静的フィールドは同名のものが使えないので、
宣言するときに意識すればよく、使うときに混乱することはないですし。


今回の話題はインスタンス メンバか静的メンバかを区別したいがためだけのものではないと思います。(最後にアクセス範囲のことも主張しておられるようなので無用なつっこみですね。すみません)

引用:

thisとかは、確かに重要と言えば重要なんですが。
常に注釈としてつけるのは、帰って分かりにくいと思うのです。
細かいことまでいちいち全部書いてあるのがわかりやすいというものでもないでしょう。
雑多な情報が全部書いてあるとかえって見にくくなることもあります。


重要なものだけマークしたい。 でなければ重要なものが隠れてしまうということですね。 この考え方自体には強く同意致します。 ただ (あくまでも私の場合になってしまいますが) this をすべて付けるとしても、そのメンバの数はそれほど多くないことが多いです。 むしろ多くなった場合は、Private 以上のアクセス修飾子を持つメンバが多すぎやしないかとクラス設計を見直すかもしれません。(今のところはないですが)

引用:

上で上がっている薬品のカラーリングの例で言うと、地味に背景色程度ですませていれば有用ですが、派手な飾りをべたべたと貼り付けて、肝心の薬品名が目立たなくなるくらいでうざい、という感じでしょう。


このメタファはちょっと誤解を招くかもしれません。 "薬品名が肝心" という記述より、多くの人はこれを "変数名" が喩えられたものだと考えると思います。 しかし 1 つの変数の単位で変数名が目立たなくなってしまうわけではありません。

次に薬品をクラスと喩えた場合で考えると、'this' というのはインスタンスそのものなのですから、外部に主張するために貼られた 「薬品名ラベル」 は適当な喩えではなくなります。

ちょっと範囲を広げて、「ある収納スペース (クラス) にある複数の薬品 (クラス内のメンバ) で~」 と考えると、今度は 'this' を付けるという喩えに困ってしまいそうです。 自分で考えておいて突っ込みますが、この例だとメソッドが何に当たりメソッドの中のローカル変数は何であるかが説明しにくそうです。

ただ仰っていることは伝わるとは思います。

引用:

そもそも、一度に考えなくてはならないことを狭くするために、アクセスできる範囲を制限しているのに、アクセスする範囲のことを常に頭に置いておかなくてはならないというのでは、本末転倒なのではないでしょうか?


"一度に考えなくてはならないことを狭くするために" とありますが、これはちょっとおかしくないでしょうか? this を付けるという場面 (位置) は、そのメソッドのローカル変数にもインスタンス内の Private メンバにもアクセスできますよね。 私の読み違いであれば申し訳ありません。

引用:

ということで。
thisはつけないほうが、可読性、ひいては保守性や拡張性が上がるものだと思っていました。


この結論がちょっとわかりませんでした。 "可読性" は個人の主観なのでともかくとして、this を付ける / 付けないが "保守性" や "拡張性" にどのように直結しているとお考えなのでしょうか? これでは this を付ける派のクラス設計が、this をつけなければ明確でないほど読みにくい / 拡張しにくいと仰られているように見えてしまいます。

これも私の読み違いであれば、詳しいご説明をして頂けると幸いです。

引用:

ここの議論を聞いていて、新人が混乱するというのとかは、一理あるかと思いましたけどね。


新人はあくまで一例で、自分を除く他人全員のことを考えたいと考えています。 もし私のユニットで this を付けない方が良いという人が上回れば (人数だけの問題ではないのですが) 何の躊躇もなく変えてしまうと思います。

そういう意味でも、こちらのスレッドにはかなり期待しております。

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
よねKEN
ぬし
会議室デビュー日: 2003/08/23
投稿数: 472
投稿日時: 2007-07-10 10:34
どっちでもいい派ですが、全部にthisを付けるのは「くどい」
とも言ってますので、その理由について。
#thisは全部付けろ、全部付けるな(必須のものは除く)は
#どちらもあまり賛同できないのですが、それなりに理由はあります。
#ルールが既にある場合は賛同できなくてもそれに従いますよ、もちろん。

私の場合、基本的にm_XXXのようにインスタンス変数はそれとわかる命名をします。
(m_は単にアンダーバーを前/後ろにつけると適宜、その人に応じて読み替えてもらってもよいです)
この場合、thisは冗長なだけなんですね。
#入力補完のためにthis.と打つということはあってもこれは誤認を防ぐという理由ではありません

引用:

nagiseさんの書き込み (2007-07-09 14:17) より:
私はスコープの違いで似て非なる名前を付けたくはないのですね。
スコープといった(広義の)名前空間が違う場合に同名でも違うものとして認識するように
わざわざ言語が対応しているんだから、人間がそこを変える対応をするというのが腑に落ちない。
しかし、このあたりは感情的なものなのかもしれません。



とおっしゃっているように、
nagiseさんの「this」があった方が誤認がなくてよい、という意見は、
「インスタンス変数、ローカル変数などで同名を積極的に使いたい」
という前提に立ったものだと思っています。
つまり、コーディング規約においてどういうルールを採用するかで
この辺は意見が分かれるのが自然だと思います。

なのですが、その前提が抜けてやしませんかね?
(とりあえずインスタンス変数、ローカル変数しか話に出ていないようなので、
それらに絞ってコメントしています)

余談ですが、過去スレ(Javaでのthis)と違って今回はC#なので、
仕事上のコーディングルールなら、VB.netも頭に入れて考えますし、
かつ、VisualStudio前提となると思っています。
私の場合、VB.netのことも頭にあるから特にインスタンス変数は区別するために
プレフィックスを付けたいのですよね。C#ではC#の流儀に合わせるべきとか
意見はあるでしょうが、仕事上のルールなら数は少ない方がいいので、
同じ.NET系では極力統一したいところです。もちろん言語仕様からくる制約なども違うので、
それぞれを意識したカスタムルールとして分岐する部分がでてくると思います。
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2007-07-10 10:56
引用:

まあ要するにどっちが正しいとかどっちの方が絶対的に合理的なんていうことはなくて、
対象とする開発者やそのレベル、人によってどの程度のやり方が合理的かは変わるという
ただそれだけのことを言いたかっただけです。


同意します。私は今のところthisをつけるほうが合理的とは思っていますが、
それが絶対の真実だと崇拝しているわけではない
私は、ちゃんと条件を示したはずです。
多人数のプロジェクトであること、新人なども混在したプロジェクトであること。
それは「よくある開発現場」であるように努めたつもりです。
そして、その条件においてはthisをつけることに合理性があると主張している。

その前提ではない場合、少数精鋭開発といった場合や、エディタの種類などで
thisをつけないほうがよい場合もあることでしょう。
先の囚人氏とのやり取りもその一端ですね。そういう議論を否定したことは一切ない。
ですから、私は

引用:

nagiseさんの書き込み (2007-07-09 18:03) より:
では、合理的ではない環境というのはどういう環境なのかを述べてください。


と、前提が違うというなら前提を述べよ、と言ったわけですが、なちゃ氏の回答はありません。
前提が違えば結論は違うはず。その前提の提示をまず行うべきでしょう?
前提がなんだろうとthisをつけろ!と主張しているわけではないことをご理解いただきたいと思います。

引用:

最初、
>開発者の感じる、うざい、くどいって
>結構重要だと思うのですよ。
と書いただけで、

>心理的なストレスは確かに重要な考慮事項ではありますが、
>誤認するほうがよほど問題なのでそこは理由あって譲りません。

>いえね、個人でプログラムしているんならなんでもいいんです。

という流れになってしまったので、まるで私が誤読よりもめんどくさいかどうか、
気分的なものの方が大事だと主張しているかのように言われてしまったので
(言われているように感じられたので)誤解されているようだ、と書きました。

もともとあれを書いたのは、表現はうざい、くどい、であっても、
そこにはプログラムの読みにくくなるという意味が含まれているのでは、
うざい、くどいという表現だけから、一概に軽視してよいものでもないのでは、
というようなことが言いたかったのです。


私の発言からの引用部にあるとおり、「心理的なストレスは確かに重要な考慮事項」
と私は認めています。私は心理面など、数字にしにくい部分も重視する主義なので
なちゃ氏の主張は賛同するところが大きい。

しかし、プロジェクトでの開発という前提をもってすれば、生産性向上のためには
そういったものは優先度は低いよね、というのが主張です。
なお、ここでは誤認により生産性が下がることを危惧しています。
誤認を元にバグを作って生まれるストレスのほうがよほど大きいと考えているからです。
しかも、経済的損失も大きいですしね。

nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2007-07-10 11:12
引用:

よねKENさんの書き込み (2007-07-10 10:34) より:
nagiseさんの「this」があった方が誤認がなくてよい、という意見は、
「インスタンス変数、ローカル変数などで同名を積極的に使いたい」
という前提に立ったものだと思っています。


ちょっと主張が後だしになってしまっていますが、お気を悪くなさらずに。

私がthisをつけろ、つまりフィールドと一時変数を区別せよ、というのは
オブジェクトのステータスの変更と言うものに対して特に注意を払え
ということがあります。

状態遷移をイメージしながらコーディングしますよね?
それは、コーディング時点でも注意を払うべきだし、またレヴュー時点でも
非常に注意して精査するところです。

とくに、マルチスレッド下ではフィールドの変更は注意しすぎてしすぎるということはない。

引用:

つまり、コーディング規約においてどういうルールを採用するかで
この辺は意見が分かれるのが自然だと思います。

なのですが、その前提が抜けてやしませんかね?
(とりあえずインスタンス変数、ローカル変数しか話に出ていないようなので、
それらに絞ってコメントしています)



こちらは重要なことだと思います。
確かによねKEN氏の以下のようなルールの下ではthisは冗長といえるでしょう。

引用:

私の場合、基本的にm_XXXのようにインスタンス変数はそれとわかる命名をします。
(m_は単にアンダーバーを前/後ろにつけると適宜、その人に応じて読み替えてもらってもよいです)
この場合、thisは冗長なだけなんですね。



ただ、私見では冗長なのはm_の方ではないかな、と思いました。
言語仕様で用意されているthis.の記法と
命名ルールによるm_のどちらを優先するか?ということになるのかな?
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2007-07-10 11:43
引用:

よねKENさんの書き込み (2007-07-10 10:34) より:

私の場合、基本的にm_XXXのようにインスタンス変数はそれとわかる命名をします。
(m_は単にアンダーバーを前/後ろにつけると適宜、その人に応じて読み替えてもらってもよいです)
この場合、thisは冗長なだけなんですね。


うちの場合は 'm_' に限らずプリフィクスを嫌うメンバが多かったです。 その理由はと聞くと 「(m_ の場合ですが) Shift キーが面倒」 「this は打ち慣れているぜ」 「文字の色が変わるからわかりやすい」 というものでした。 これに関しても 「その程度の理由か」 という意見もきっとあるでしょう。

引用:

とおっしゃっているように、nagiseさんの「this」があった方が誤認がなくてよい、という意見は、「インスタンス変数、ローカル変数などで同名を積極的に使いたい」という前提に立ったものだと思っています。


nagise さんがすでに書かれているので多くは割愛しますが、この姿勢はないです。 強いていうならば、どうせ少ないのだから明示しようよ。 目立たせようよ。です。

引用:

私の場合、VB.netのことも頭にあるから特にインスタンス変数は区別するためにプレフィックスを付けたいのですよね。C#ではC#の流儀に合わせるべきとか意見はあるでしょうが、仕事上のルールなら数は少ない方がいいので、同じ.NET系では極力統一したいところです。もちろん言語仕様からくる制約なども違うので、それぞれを意識したカスタムルールとして分岐する部分がでてくると思います。


この時点でも個人差がありますね。 C#, J#, C++/CLI では this、VB では Me の方が視覚的にわかりやすいと感じる人も多いでしょう。 色に関してはエディタによる前提が必要です。 あとは 「見慣れ」 とか本当に個人差でしかないと思います。「直感でわかる人の数」 を重点に this なのかプリフィクスなのか決めれば良いとは思います。

ところで、私は this 付けるよ派にとりあえず回ってはいるものの、プロパティ アクセサ内 (最初に少し書きました) と、Form のコントロールの初期化の時は、「くどい」 という気持ちがあります。

プロパティ アクセサ内に用いるプロパティ変数は先頭にアンダースコアを付けて 「直接参照するな!」 という姿勢で命名していますので、this を付ける意味はあまりない。 プロパティ アクセサ内で何をするかくらいは自明なので明示する意味はない。 別の場所からこのフィールド (プロパティ) に直接アクセスすることがない。 という理由です。

コントロールの初期化などに関しては、VB ならば With ステートメント、一部の言語ではカスケード機構が使えますが、Visual Studio Code Generator が自動生成するコードは丹念に "this" を付けてくれていますので、とりあえず倣うことにしてます。 この場合は "this." をコピペしています。 ただし、これをもって何かを主張する気はないです。 むしろ this を付けないの 「くどい」 に同調している部分は少なからずありますよという意図です。

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌

スキルアップ/キャリアアップ(JOB@IT)