- - PR -
現在のインスタンスを参照するthisキーワード、付ける？ or 付けない？
| 投票結果総投票数：259 | |||
|---|---|---|---|
| 付ける |  |
99票 | 38.22% |
| 付けない | |
66票 | 25.48% |
| 付けたり付けなかったり | |
94票 | 36.29% |
| |||
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-07-15 09:08
クラス内だとないでしょうね。 Private メンバで持っているということはパラメータで利用する必要がないです。(というよりそうでないとクラス設計が変なことが多いです) もちろんクラス メンバで持っている以上、コンストラクタでは同名になるパターンは多いですが (BCL のコンストラクタはほとんどそうなっている) コンストラクタでは気をつけるでしょう。
それはないでしょうね。 少なくとも私に関して言えば、単にクラスのメンバなのだと視覚的に明示化する (アピールする) 程度の意味合いしかないです。 結局のところ個人の視点による拘りだったり慣習に近いものだと思います。 こういったものは、たとえば文書の書き方にも通ずるものがありますね。 やはりコモンセンス的な優劣はつけがたいような気がします。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||
|
投稿日時: 2007-07-16 12:52
うーん。 まりもさんの意見では「とくに目立たせる必要はない」とおっしゃっているように捉えられます。 そうなると「注意喚起のために目立たせる必然性がある。」という部分に同意が取れていないということになるのではないでしょうか。 目立たせる必要があるから ⇒ thisをつける、プレフィックスをつける という話において、thisとかプレフィックスをつけて目立たせることもないんじゃないの？とおっしゃっているように捉えたのですが、どうでしょうか？ 私は 「インスタンス変数をいじるってのはクラスの状態遷移だから重要なんだよ！ だから、キーワードハイライトがついて視覚的にもどーんと目立つようにして 注意喚起してうっかりミスするようなことを回避するようにしないと あとでとんでもないバグを生み出したりするんだよ！」 ということを主張してきました。 このスレでも出しましたが、たとえ話で医療現場における薬の取り違いのミスという例を挙げていました。 お気悪くなさらないでくださいね。まりも氏の発言は 「いや、そんなことしなくても薬なんて取り違えないよ。紛らわしくない名前がちゃんと書いてあるわけだし」 というようにたとえられる訳です。 私がしつこく注意喚起と言っているのは、人間というものはミスをするものだ、 という前提に立ってなおもそのミスを減らそうという論点を伝えたいがためです。 ソースの読み手が機械だったら、別に間違えるとかいうことがないのでどうでもいいんですけどね。 （実際、コンパイラはthisとかプレフィックスなくても読み間違えませんよね？） | ||||||||||||
|
投稿日時: 2007-07-16 16:35
ちょっとそのへん話が本筋からそれ気味なので、わかりにくくなっていますね。すみません。 thisのみならず、ほかのアクセス範囲を制限する方法も含めた話としているのです。 そのなかで、thisは一番分かりにくい状況なのかもしれませんが。 thisのスレなので、thisの話でいくと。 thisをどう使うかの前に、なぜthisというものが用意されているのか。 それは、変数の中に、メソッド内変数というものと、クラスフィールドというものがあるからです。 では、なぜそういうものが用意されているかというと。 なければプログラムができないわけではありません。 全部グローバルにおいておいても、きわめて注意深くプログラミングしていけば理論上は大丈夫なはずです。 実際。実行時にメモリ上に置かれている変数は、そんな感じでしょう。 しかし実際にはそうはいかない。 変数を使うたびに、その変数の使われる範囲をいちいち考慮していては、 肝心のプログラムに向ける余裕がなくなるわけです。 ですから、宣言する時点で、使う範囲をしっかり考えて明記しておき、 使うときはなるべく何も考えなくて済むようにする。 これが、アクセス範囲というものが現在のプログラム言語にある理由だと思うのですよ。 と、これで話がアクセス修飾子とかスコープのはなしであるなら、これできれいに話は収まるのです。 定義するときに利用可能な範囲を考えて明記しておけば、使うときにそれに反した使い方をしたら、コンパイラが全部教えてくれる。 しかし、thisのつけるつけないに関しては、そうすっきり話は収まりません。 使用時になにも考えなければ、thisを書き忘れてバグのもとになることもあります。 とはいえ、アクセス範囲の指定の中で、thisのみが全く異なった枠組みになっている、と考えるのも無理があるのではないでしょうか。 ほかの、アクセス修飾子やスコープなどのときにあわせて考えれば、 変数を使用するときに必ず、その変数のアクセス範囲を意識して、忘れずに明示的に指定しておく必要がある、という使い方はきれいではないと思います。 そもそも、そういう使い方をすることを推奨してC#という言語が設計されていたとするなら、他のアクセス範囲と同じように、間違えたら即コンパイルエラーとなるようなつくりになっているはずではないでしょうか？ thisに対応する、メソッド内変数を指定する単語が用意されていて、変数名が競合するときはそれをつけないとコンパイルエラーになるとか。
なるほど。そういう視点での発言でしたか。 納得しました。 となると、答えを一つに絞るのは難しそうですね。 答えは人によって違ってくるでしょう。 その人が今までにマスターした言語の特性にもよってくるでしょうし。 | ||||||||||||
|
投稿日時: 2007-07-16 17:07
そういう言い方をしても間違ってはいません。 しかし、もっと正確な言い方をするならば。 違いがあることをわかるようにする必要はあるが、それはthisやプリフィックスのような機械的な方法で行うのではなく、違いがわかりやすい変数名をつけるという方法で行うべきだ、ということです。
その例については、先にもラベルの貼りすぎの薬瓶の例などもあげましたし。 また、よくよく考えると、もっと重要な問題点があるような気がしてきました。 薬のラベルのカラーリングは、実際に効果を上げているものでしょう。 それは、間違いを減らすようにきちんとシステムを考えて動いているからです。 実際にどういう手順に従って動いているかは知りませんが。 たぶん、薬瓶を用意するときに、どの色にするかちゃんとリストになっていて、色をつけた時にちゃんとチェックするように手順書に書いてあるとか、 もっと合理的にやっているなら、ラベルの印刷のときにデータベースから自動的に色情報を取ってきて自動的にカラーで印刷するとか、 そういうことになっていると思います。 薬瓶をとってくるようなあわただしい時にやるべき判断を減らし、それを落ち着いてチェックできるような時にまとめて行うことによって、精度を上げているのです。 プログラムで言うと、コンパイラがちゃんとチェックしてくれている、という状況に近いでしょう。 しかしこれが。 薬瓶をとってくるときに、とってくるときの看護士の判断で色をつける、というシステムだったらどうでしょう。 色をつけるときに、薬の名前のみを見ていた時と同程度の確率で、ミスが発生することでしょう。 そしてその後、その色を信用することによって、ミスは拡大されることになります。 thisの場合は、このときに近いのではないでしょうか？ thisをつける/つけないの確認は、変数を使用するたびごとに、目視で行わねばなりません。 そして、コンパイラはチェックしてくれません。 | ||||||||||||
|
投稿日時: 2007-07-16 17:15
いえ、今時の高機能なIDEではそれをチェックすることができてしまいます。 なので、さきのまとめでは、そういった機能を持たない環境と 可能な環境の違いを考慮して以下のように記述してあります。
これは重要な前提事項ですので、引用元の時点で強調されています。 | ||||||||||||
|
投稿日時: 2007-07-16 19:05
原理的に不可能ではないか、と思いましたが。 つけなくてもバグにならないところに関しては、可能ですね。 つけないとバグになるところはどちらにせよテストで確認せねばならないので、それで十分なのか。 確実につけられている保証があるなら。 安心して書いてあることを信用できるので、つける効果がありますね。 しかし。 Visual Studeoでできましたっけ？ | ||||||||||||
|
投稿日時: 2007-07-16 22:49
オブジェクト指向うんぬんの話と繋がっているように見えてしまったのがまずかったようですね。 どうやら "考える必要がないようにする" というのは実際にコーディングする時の this を付けるかどうかを "考える" という話だったようですね。 しかし私はクラス内部である以上は重要な意味を持つため、Private メンバであるという意識を持たせるようコーディング時にも考えさせるべきだと考えています。 そしてそれは私にとっては this であるというだけのようです。 と、このようにこのあたりはもはやスタイルの問題でしかなさそうです。 ところで命名を気をつければ "this 自体" は考える必要がなくなるかもしれませんが、命名を考える必要は生じると思います。 プリフィクスや this であれば考える必要がなくそれを付加するだけに留まります。 何にせよ 「似て非なるもの」 の方が直感で理解しやすいと考えています。 またグループ開発時には個人のセンスで揺らぎが生じないようルールを設ける必要があるわけですが、プリフィクス / サフィクス や this でないとルールとして明示化しにくい、もしくは揺らぎが生じやすくなると思います。 このあたりはどうやってカバーしていくことが考えられるのでしょうか? 個人的には非常に難しい問題のように思います。 いずれにしても、やはりこれは個人のスタイル依存だと思いますので、最も良いのは 「新しい開発グループになる都度、議題として挙げる」 ということでしょうね。 全体で一環していればもともとの目指すところは似ているので問題はなさそうです。 私はガイドラインに書かれていないことは、MSDN ライブラリのサンプルや BCL などから掻い摘んでルールを作るようにしています。 が、それは決して万人にとって当たり前のルールではない可能性を十分に持っているというのが良くわかりました。 ありがとうございます。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||
|
投稿日時: 2007-07-17 12:08
.NET系の開発環境については私は疎いのですが… 少なくともJava開発で広く用いられているEclipseというIDEではCheckstyleプラグインでチェックが可能です。 調べてみたらこういう過去スレを見つけました。 http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=23447&forum=7 詳しい方、フォローいただけると助かります。 | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。