- - PR -
現在のインスタンスを参照するthisキーワード、付ける? or 付けない?
投票結果総投票数:259 | |||
---|---|---|---|
付ける | ![]() |
99票 | 38.22% |
付けない | ![]() |
66票 | 25.48% |
付けたり付けなかったり | ![]() |
94票 | 36.29% |
|
投稿者 | 投稿内容 | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-07-10 01:53
個人的には、必要ならつければいいかなと思ってます。
多くの事例を見たわけではないので、感覚なのですが、、 thisをつけないとインスタンス変数かどうかわかりにくいというのは、 バッドスメルな感じがします。 本当は、エディタがそれを識別して色を付けてくれれば良いんですけどね。 | ||||||||||||||||||||||||||||
|
投稿日時: 2007-07-10 02:29
上手く説明できないのですが、いちいち this を付けるというのは、
オブジェクト指向の本質に根底から反しているように感じます。 せっかく抽象度の高いレベルで思考していたのを実装レベルまで引きずり落とす愚行、ではないかと。 私がthisを使うのは、 (1) 各フィールドと一対一対応するパラメータを持ったコンストラクタ。 パラメータ名とフィールド名を同じにするので、thisを付けて区別する。 (2) 比較や代入を行うメソッド。 ほぼ対等な2つのインスタンスが関与するので、this と that で参照する。 だけです。 C++なら、(2)のような例は メソッドではなくて2引数のfriend関数にした方が気持ちいいけど。 | ||||||||||||||||||||||||||||
|
投稿日時: 2007-07-10 09:11
いかにもthisを付けるやつが構造化すらできてないと決め付けている言い方をしているやつがいるが・・・
こりゃ不毛な議論を招くもとであると最初にいっておこう。 (この段階でだが)自分視点でしか意見を書けていないと非常に見苦しい。 しかし少し前にthisつけない派の理由にようやくそれらしい主張がでてきた。 「すべてにつけると目立たせるべきものが目立てない」というね。 これは期待age。 [ メッセージ編集済み 編集者: ぶさいくろう 編集日時 2007-07-10 09:16 ] | ||||||||||||||||||||||||||||
|
投稿日時: 2007-07-10 10:10
今回の話題はインスタンス メンバか静的メンバかを区別したいがためだけのものではないと思います。(最後にアクセス範囲のことも主張しておられるようなので無用なつっこみですね。すみません)
重要なものだけマークしたい。 でなければ重要なものが隠れてしまうということですね。 この考え方自体には強く同意致します。 ただ (あくまでも私の場合になってしまいますが) this をすべて付けるとしても、そのメンバの数はそれほど多くないことが多いです。 むしろ多くなった場合は、Private 以上のアクセス修飾子を持つメンバが多すぎやしないかとクラス設計を見直すかもしれません。(今のところはないですが)
このメタファはちょっと誤解を招くかもしれません。 "薬品名が肝心" という記述より、多くの人はこれを "変数名" が喩えられたものだと考えると思います。 しかし 1 つの変数の単位で変数名が目立たなくなってしまうわけではありません。 次に薬品をクラスと喩えた場合で考えると、'this' というのはインスタンスそのものなのですから、外部に主張するために貼られた 「薬品名ラベル」 は適当な喩えではなくなります。 ちょっと範囲を広げて、「ある収納スペース (クラス) にある複数の薬品 (クラス内のメンバ) で~」 と考えると、今度は 'this' を付けるという喩えに困ってしまいそうです。 自分で考えておいて突っ込みますが、この例だとメソッドが何に当たりメソッドの中のローカル変数は何であるかが説明しにくそうです。 ただ仰っていることは伝わるとは思います。
"一度に考えなくてはならないことを狭くするために" とありますが、これはちょっとおかしくないでしょうか? this を付けるという場面 (位置) は、そのメソッドのローカル変数にもインスタンス内の Private メンバにもアクセスできますよね。 私の読み違いであれば申し訳ありません。
この結論がちょっとわかりませんでした。 "可読性" は個人の主観なのでともかくとして、this を付ける / 付けないが "保守性" や "拡張性" にどのように直結しているとお考えなのでしょうか? これでは this を付ける派のクラス設計が、this をつけなければ明確でないほど読みにくい / 拡張しにくいと仰られているように見えてしまいます。 これも私の読み違いであれば、詳しいご説明をして頂けると幸いです。
新人はあくまで一例で、自分を除く他人全員のことを考えたいと考えています。 もし私のユニットで this を付けない方が良いという人が上回れば (人数だけの問題ではないのですが) 何の躊躇もなく変えてしまうと思います。 そういう意味でも、こちらのスレッドにはかなり期待しております。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||||||||||||||||||
|
投稿日時: 2007-07-10 10:34
どっちでもいい派ですが、全部にthisを付けるのは「くどい」
とも言ってますので、その理由について。 #thisは全部付けろ、全部付けるな(必須のものは除く)は #どちらもあまり賛同できないのですが、それなりに理由はあります。 #ルールが既にある場合は賛同できなくてもそれに従いますよ、もちろん。 私の場合、基本的にm_XXXのようにインスタンス変数はそれとわかる命名をします。 (m_は単にアンダーバーを前/後ろにつけると適宜、その人に応じて読み替えてもらってもよいです) この場合、thisは冗長なだけなんですね。 #入力補完のためにthis.と打つということはあってもこれは誤認を防ぐという理由ではありません
とおっしゃっているように、 nagiseさんの「this」があった方が誤認がなくてよい、という意見は、 「インスタンス変数、ローカル変数などで同名を積極的に使いたい」 という前提に立ったものだと思っています。 つまり、コーディング規約においてどういうルールを採用するかで この辺は意見が分かれるのが自然だと思います。 なのですが、その前提が抜けてやしませんかね? (とりあえずインスタンス変数、ローカル変数しか話に出ていないようなので、 それらに絞ってコメントしています) 余談ですが、過去スレ(Javaでのthis)と違って今回はC#なので、 仕事上のコーディングルールなら、VB.netも頭に入れて考えますし、 かつ、VisualStudio前提となると思っています。 私の場合、VB.netのことも頭にあるから特にインスタンス変数は区別するために プレフィックスを付けたいのですよね。C#ではC#の流儀に合わせるべきとか 意見はあるでしょうが、仕事上のルールなら数は少ない方がいいので、 同じ.NET系では極力統一したいところです。もちろん言語仕様からくる制約なども違うので、 それぞれを意識したカスタムルールとして分岐する部分がでてくると思います。 | ||||||||||||||||||||||||||||
|
投稿日時: 2007-07-10 10:56
同意します。私は今のところthisをつけるほうが合理的とは思っていますが、 それが絶対の真実だと崇拝しているわけではない。 私は、ちゃんと条件を示したはずです。 多人数のプロジェクトであること、新人なども混在したプロジェクトであること。 それは「よくある開発現場」であるように努めたつもりです。 そして、その条件においてはthisをつけることに合理性があると主張している。 その前提ではない場合、少数精鋭開発といった場合や、エディタの種類などで thisをつけないほうがよい場合もあることでしょう。 先の囚人氏とのやり取りもその一端ですね。そういう議論を否定したことは一切ない。 ですから、私は
と、前提が違うというなら前提を述べよ、と言ったわけですが、なちゃ氏の回答はありません。 前提が違えば結論は違うはず。その前提の提示をまず行うべきでしょう? 前提がなんだろうとthisをつけろ!と主張しているわけではないことをご理解いただきたいと思います。
私の発言からの引用部にあるとおり、「心理的なストレスは確かに重要な考慮事項」 と私は認めています。私は心理面など、数字にしにくい部分も重視する主義なので なちゃ氏の主張は賛同するところが大きい。 しかし、プロジェクトでの開発という前提をもってすれば、生産性向上のためには そういったものは優先度は低いよね、というのが主張です。 なお、ここでは誤認により生産性が下がることを危惧しています。 誤認を元にバグを作って生まれるストレスのほうがよほど大きいと考えているからです。 しかも、経済的損失も大きいですしね。 | ||||||||||||||||||||||||||||
|
投稿日時: 2007-07-10 11:12
ちょっと主張が後だしになってしまっていますが、お気を悪くなさらずに。 私がthisをつけろ、つまりフィールドと一時変数を区別せよ、というのは オブジェクトのステータスの変更と言うものに対して特に注意を払え ということがあります。 状態遷移をイメージしながらコーディングしますよね? それは、コーディング時点でも注意を払うべきだし、またレヴュー時点でも 非常に注意して精査するところです。 とくに、マルチスレッド下ではフィールドの変更は注意しすぎてしすぎるということはない。
こちらは重要なことだと思います。 確かによねKEN氏の以下のようなルールの下ではthisは冗長といえるでしょう。
ただ、私見では冗長なのはm_の方ではないかな、と思いました。 言語仕様で用意されているthis.の記法と 命名ルールによるm_のどちらを優先するか?ということになるのかな? | ||||||||||||||||||||||||||||
|
投稿日時: 2007-07-10 11:43
うちの場合は 'm_' に限らずプリフィクスを嫌うメンバが多かったです。 その理由はと聞くと 「(m_ の場合ですが) Shift キーが面倒」 「this は打ち慣れているぜ」 「文字の色が変わるからわかりやすい」 というものでした。 これに関しても 「その程度の理由か」 という意見もきっとあるでしょう。
nagise さんがすでに書かれているので多くは割愛しますが、この姿勢はないです。 強いていうならば、どうせ少ないのだから明示しようよ。 目立たせようよ。です。
この時点でも個人差がありますね。 C#, J#, C++/CLI では this、VB では Me の方が視覚的にわかりやすいと感じる人も多いでしょう。 色に関してはエディタによる前提が必要です。 あとは 「見慣れ」 とか本当に個人差でしかないと思います。「直感でわかる人の数」 を重点に this なのかプリフィクスなのか決めれば良いとは思います。 ところで、私は this 付けるよ派にとりあえず回ってはいるものの、プロパティ アクセサ内 (最初に少し書きました) と、Form のコントロールの初期化の時は、「くどい」 という気持ちがあります。 プロパティ アクセサ内に用いるプロパティ変数は先頭にアンダースコアを付けて 「直接参照するな!」 という姿勢で命名していますので、this を付ける意味はあまりない。 プロパティ アクセサ内で何をするかくらいは自明なので明示する意味はない。 別の場所からこのフィールド (プロパティ) に直接アクセスすることがない。 という理由です。 コントロールの初期化などに関しては、VB ならば With ステートメント、一部の言語ではカスケード機構が使えますが、Visual Studio Code Generator が自動生成するコードは丹念に "this" を付けてくれていますので、とりあえず倣うことにしてます。 この場合は "this." をコピペしています。 ただし、これをもって何かを主張する気はないです。 むしろ this を付けないの 「くどい」 に同調している部分は少なからずありますよという意図です。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 |