- - PR -
現在のインスタンスを参照するthisキーワード、付ける？ or 付けない？
| 投票結果総投票数：259 | |||
|---|---|---|---|
| 付ける |  |
99票 | 38.22% |
| 付けない | |
66票 | 25.48% |
| 付けたり付けなかったり | |
94票 | 36.29% |
| |||
| 投稿者 | 投稿内容 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-07-10 23:52
私の場合は、thisキーワードを使用せずに、インスタンス変数に
プレフィックス(_)をつけて区別します。 thisキーワードではなく、プレフィックスを使用する理由は、 （thisキーワードやプレフィックスの付け忘れを考慮した場合、） 事前にインスタンス変数が全てプレフィックス付きで定義されていることを 確認しておけば、プレフィックスの付いていない変数は全てローカル変数 であると判断できるからです（メソッド内での定義の有無を逐一確認せずに済む）。 # thisキーワードを使用する場合はこれができません。 | ||||||||||||||||||||||||||||
|
投稿日時: 2007-07-11 00:02
気を悪くするとかは特にありませんが(^^; 「thisを付けることで誤認を防ぐ」という主張と一緒に 「同じものは同じ名前で付けたい」ということも主張されていたので、 セットでの主張だと考えていました。 オブジェクトのステータスの変更に注意が払えればよい (平たく言えば、インスタンス変数が目立てばよい、でよいですよね？) ということであれば、好み的なことを抜きにすれば、 thisでなくプレフィックスを付けるというのも場合によって"あり"ということでしょうか。
インスタンス変数を目立たせるという点ではどちらにも同様の効果はありますね。 ところで、「インスタンス変数の使用にthisを必ず付けること」 というルールにした場合、どうやってチェックされるのでしょうか？ (FxCopは使ったことがないのですが、この辺でチェックできるのでしょうか？ JavaでEclipseの場合でもCheckStyleにそういう定義があったか覚えがありません) プレフィックスを付けるルールの場合は、インスタンス変数の定義部分を チェックすれば守られているかどうかを判断できます。 #CheckStyleならチェック可能ですが、FxCopについてはこれまた知りません。 #が、このくらいなら目検で大丈夫かと思います。 | ||||||||||||||||||||||||||||
|
投稿日時: 2007-07-11 00:27
そういうメンバーなら、プレフィックス案でなくthisを付ける案にする方が合理的だと思います。 十分な理由だと思いますよ。
じゃんぬねっとさんは、「インスタンス変数とローカル変数を同名で扱いたい」というような主張はされていなくて、 「あくまでインスタンス変数だと明示できるから」という主張と理解しています。
そうですね。"「直感でわかる人の数」 を重点に"という部分は特に重要だと思います。 あくまで私見ですが、なちゃさんが、 「ところで。 開発者の感じる、うざい、くどいって 結構重要だと思うのですよ。」 とコメントされた理由もこういうことだと思っています。 ↓以下は前から考えていたことというより、どちらかというと このスレを何度か読み直して、「うざい」「くどい」の理由を考えた流れで出てきた考えです。 私の場合、Java、C#、VBでthisやMeを必ず付けるか/付けないかについて どちらかに統一すべきでは？と何度か考えました。で、今までプログラミングしてきて、 結局、一貫してどちらに統一するのもなんかしっくりこないんですよね。 その結果で今はどっちでもいい派なんですが。 これは完全に感覚的なもので、あまり合理性はないと思います プロジェクトとしてルールで決まっていれば、それに従いますが、 どちらの方針にしても、それに合わせるためにそれ相応の工数がかかり、 かつ、(個人的にどちらでもよいと思っている部分に労力がかかることが)ストレスにもなる なぁと思っていました。そして、それは他のプログラマにも少なからず当てはまるのではないかなと。 | ||||||||||||||||||||||||||||
|
投稿日時: 2007-07-11 00:42
JavaでEclipseの場合はCheckStyleでいけますね。 このような機械チェックによって全てにthisが付いていることを保障できるという前提の場合と、 機械チェックが出来ない環境という前提では結論は大きく違うとも思います。 ネットクラゲ氏の意見も機械チェックがない環境での結論ですよね。 また、thisを付け忘れて
としてしまった場合なども警告がでますので、このIDE下では 名前が同じであるが故の実用上の問題はありません。 「オブジェクトのステータスの変更と言うものに対して特に注意を払え」 という理由はインスタンス変数を目立たせる理由としては十分すぎると思いますが、 さて、命名規約で目立たせようか、this（あるいはMe）で目立たせようか、となれば 言語規約の機能であるthisやMeのほうが誤解がないと思います。 thisやMeは本来つけることができないものには付けられないわけですから、 言語の機能としてサポートされているキーワードの強みがありますね。 また、こういった標準キーワードであれば多くのエディタでハイライトされることが 期待できるわけですから、あえてプリフィックスを採用する積極的な理由はないと思います。 | ||||||||||||||||||||||||||||
|
投稿日時: 2007-07-11 00:43
ちょっと抽象的なようにも思えますが、私もまさに、こういうことが言いたいのだと思います。
これは大変説得力がありますね。確かにあんまり数はないはずです。結構見にくいような気がしたものだが。気のせいだったのか。 気のせいの可能性も高いですが、もし気のせいでないとするなら。 「必ず」つけるということになると、「thisが付いている」ということが意味を持つと同時に、「thisが付いていない」ということも一つの記号となり、その意味を見るたびに読み取る必要が出てきます。 その辺ともども、頭に負荷をかけているような気がします。
この局面だけを考えれば、その通りなのですが。 ただ、インスタンスやらスコープやらアクセス修飾子やら、変数を使える範囲を指定する数多くの手段があり、きめ細かな指定ができるようになっているのは、総じて思考を節約するためですよね？ だから総じて、その辺の機能の使い方の指針としては、宣言するときに極力考えて、使う時にはなるべく何も考えない、というのが理にかなっていると思うのです。
すみません。わかりにくかったですね。 基本的には単に、可読性というと単にプログラマーが楽をしているだけのように聞こえるけれども、それはつまり保守性や拡張性に結びつくものだから品質に大きくかかわる、と言いたかっただけなのです。 あと。 ひょっとしたら、私の設計が下手なだけなのかな、と思い前回は書きませんでしたが。 リファクタリングなんかしていて。 クラス全体で制御しようとした値が、一メソッド内に収まってしまったとか、 静的クラスにしようとしていたのだが、やっぱり継承とか使いたくなったのでインスタンスを利用することに変えたとか、そういうことはないでしょうか？ 結構そういうことがあるので、 「this」とかのアクセス範囲はあくまで実装上の工夫であり、 本当に不変な意味を持つのは変数名などの抽象的なものなのかなあという感覚で、 「this」は書かないほうがよい、と思っていたのです。 | ||||||||||||||||||||||||||||
|
投稿日時: 2007-07-11 00:51
僕は this(Me) はつけません。
確か最初に Java をやった時は無理にでもつけていたような気がするんだけれど、いつの間につけなくなったんだろう。。。 この頃 Javascript をよく触るんですが、こいつは this がないと別物として新しく束縛されたりするのでなれないとハマりますね。 Microsoft Ajax Library だと private は "_"プレフィクス であらわしていますね。 まぁこの場合は言語としてアクセス修飾子が無い所からきているかも知れませんが。 #コーディング規約があれば従いますよ。
これは確かにそうかもしれない。 unibonさんが言っているリファクタ（？）ツールがあるといい気がするなー _________________ かるあ のメモ http://karua.at.webry.info/ [ メッセージ編集済み 編集者: かるあ 編集日時 2007-07-11 00:53 ] | ||||||||||||||||||||||||||||
|
投稿日時: 2007-07-11 02:28
機械チェックができるかどうかは結論に影響が大きいのはその通りだと思います。 ちなみに"HiddenField"の設定でしょうか？ http://www.limy.org/program/java/checkstyle/coding.html (上記サイトより引用) >「同一クラス内で定義されたフィールドと同名の >ローカル変数やメソッドパラメータが存在するかどうかチェックします。」
実用上問題ないとのことですが、必ずしもそうとは言えないのではないでしょうか。
このコードの場合、 hoge2 = func2(hoge1) の行が警告されると思いますが、警告を見て鵜呑みにして修正すると this.hoge2 = func2(this.hoge1); と直されるかもしれません。 それで正しいかもしれないし、間違いかもしれませんが、最初に書いた人にしかわかりません。 さらに、 this.hoge2 = func2(hoge1); というコードが意図に沿うものだった場合、 ツールの警告が出っぱなしになりますよね。 警告は場合によって無視してよい、という運用になりませんか？ (消えない警告があるとツールの存在がデメリットにさえなります) こういった判断はツールの得意でない部分で、 hoge1がパラメータかインスタンス変数かはツールには判断できません。 環境がないので、CheckStyleを通しての実験はしていませんので、 私の想定した通りの警告にならないかもしれませんが、 私の言おうとしていることは、要するにツールは万能ではないので、 ツールが対応しているからそれでよいとは簡単に判断できないということです。 ＃この件に関して言えば、JavaやC#の言語仕様で ＃人から見た場合には曖昧な記述が許されるケースのため ＃ツールとしては警告を出すのが精一杯なので仕方ないところです
「言語規約の機能であるthisやMeのほうが誤解がない」という発想は概ね同意します。 ですが、同様に言語仕様としてthisやMeを付けることは強制していないので、 上記でコメントした通り、this、Meを付ける(コーディング規約通り)、 thisやMeを付けなくても怒られない(言語仕様通り)という問題が発生します。 (ツールである程度は確かに対応できるのですが) プレフィックス案だと命名ルールに関するツールの機能で対応できるので この件に関する曖昧さは特にありません。
言語の機能としてサポートされているキーワードの強み、 エディタでハイライトされるだろうという辺のメリットについてその通りだと思います。 ＞ALL FxCopについて情報をお持ちの方、情報提供お願いします。 | ||||||||||||||||||||||||||||
|
投稿日時: 2007-07-11 09:38
ちょっと目先を変えます。
C++でもthisを使えますし、Microsoft製のIDEであればハイライトもされるしインテリセンスも使用できます。Emacs系エディタのことは知りませんが、Vimではハイライトされますし、インテリセンスもどきの補完も使えます。 しかしC++でthisを使う人はほとんどいません。（もちろん私の知る限りにおいてですが） これは一体なぜなんでしょう？ thisを付けることによって、可読性があがったり保守性が高まったりするのであれば、C++コミュにもいくらかは波及すると思うんですが、今のところそのような予兆は感じられません。 PythonではOO機能を実装するときに、this相当のself必須という選択をしました。メソッドの仮引数でさえ、selfを記述しなければなりません。 しかし今でも「なぜselfは必要なの？」というPython newbieからの疑問（不満？）が後を絶ちません。Python FAQに「なぜselfが必要なのか」というエントリがあるくらいです。 thisをつけることによって「可読性があがったり保守性が高まったり」と感じる人がC#コミュには多いのかもしれませんが、C++やPythonの例を見ると、それは普遍的な感じ方ではないような気がします。 @ITで投票を行うC#ユーザの中では、圧倒的にthisを付ける人が多いようですが、全世界的に見てC#でthisを付ける人がやはり圧倒的に多いとすると、それは「可読性があがったり保守性が高まったり」ではない何かがあるような気がします。 じゃんぬねっとさんの「自動生成されたコードにthisがあったから」という理由が、いまのところ最もしっくり来る説だと私は思います。 | ||||||||||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。