- PR -

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

«前のページへ 1|2|3|4|5|6|7|8|9|10|11 次のページへ»
投票結果総投票数：259
付ける 99票 38.22%
付けない 66票 25.48%
付けたり付けなかったり 94票 36.29%
  • 投票は恣意的に行われます。統計的な調査と異なり、投票データの正確性や標本の代表性は保証されません。
  • 投票結果の正当性や公平性について、＠ITは一切保証も関与もいたしません。
投稿者投稿内容
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2007-07-11 09:47
まりもさん、丁寧なご返信ありがとうございます。

引用:

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

引用:

coasmさんの書き込み (2007-07-10 02:29) より:

せっかく抽象度の高いレベルで思考していたのを実装レベルまで引きずり落とす愚行、ではないかと。

ちょっと抽象的なようにも思えますが、私もまさに、こういうことが言いたいのだと思います。

実は coasm さんにも同様の返信をしようと思っておりました。 個人的には "愚行" とまで仰るからには説明して頂きたかったのですが、"上手く説明できないのですが" という前置きがありましたので控えさせて頂きました。

引用:

気のせいの可能性も高いですが、もし気のせいでないとするなら。
「必ず」つけるということになると、「thisが付いている」ということが意味を持つと同時に、「thisが付いていない」ということも一つの記号となり、その意味を見るたびに読み取る必要が出てきます。その辺ともども、頭に負荷をかけているような気がします。

少し前にあった 「目立つ目立たない」 のお話ですね。 これは私も納得しています。 極端な例かもしれませんが、Form のプロパティあたりに何かをセットする時、

コード:

    Text = "C#";

などと書かず、

コード:

    this.Text = "C#";

と書かれる方は多いと思います。 (VB6 畑ではかなり主流だったと思います) そして、Form のコンテナ内にあるコントロールは this を明示的につけない。 こうすれば、子コントロールとの区別がわかりやすいですね。 (これは一例ですが)

ところで、今さらの確認ですが "付けない" に投票された方は、こういったものさえ 「this を付けない」 から "付けない" に投票されているのでしょうか? 私はプロパティ アクセサの件があるので 「付けたり付けなかったり」 に投票しました。

引用:

この局面だけを考えれば、その通りなのですが。
ただ、インスタンスやらスコープやらアクセス修飾子やら、変数を使える範囲を指定する数多くの手段があり、きめ細かな指定ができるようになっているのは、総じて思考を節約するためですよね？

これが同調されている coasm さんの "オブジェクト指向の本質に根底から反しているように感じます" に意図するものであれば、私はそうは思いません... と書かせて頂こうかと思ったのですが、読み違いの臭いがしましたので、"きめ細かな指定" と "思考を節約できる" 事例を提示して頂けないでしょうか?

引用:

基本的には単に、可読性というと単にプログラマーが楽をしているだけのように聞こえるけれども、それはつまり保守性や拡張性に結びつくものだから品質に大きくかかわる、と言いたかっただけなのです。

つまり 「this を付けない」 と主張している方の根本の理由ということですね。 同じように 「this を付ける」 と主張している方もそういう理由で主張しているのだと思います。 ですので、別の意図があるのだと思い込んでおりました。

引用:

ひょっとしたら、私の設計が下手なだけなのかな、と思い前回は書きませんでしたが。
リファクタリングなんかしていて。
クラス全体で制御しようとした値が、一メソッド内に収まってしまったとか、

私はとりあえず一度もないです。 スコープは小さく努めるのが基本と考えていますので、考え方としてはローカル変数 (ブロック変数) が出発点です。 そこから、Private メンバに昇格するかどうかを考えるからそういった経験がないのかもしれません。

つまり逆に 「Private メンバに昇格するか...」 というパターンならあり得ますが、「あれ? メソッド内に収まってしまった Ze」 ということはないですね。 私はクラス ライブラリ系ばかり作っていますが、とりあえず今のところは経験ありません。

引用:

静的クラスにしようとしていたのだが、やっぱり継承とか使いたくなったのでインスタンスを利用することに変えたとか、そういうことはないでしょうか？
結構そういうことがあるので、

これもないですね。 ところで、こちらはどのようなパターンであり得るのでしょうか? "結構そういうことがある" と書かれていらっしゃいますので、参考までに事例を挙げて頂けないでしょうか?

引用:

「this」とかのアクセス範囲はあくまで実装上の工夫であり、
本当に不変な意味を持つのは変数名などの抽象的なものなのかなあという感覚で、
「this」は書かないほうがよい、と思っていたのです。

こちらでは "実装上の工夫" の話しかしていないと思いますよ。

具体的な失敗例はわかりませんが、「過去の苦い経験」 などにも左右されるようで、思った以上に個人に依存しているようですね。 非常に興味深いです。 近々この件でミーティングしようと思います。

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
かるあ
ぬし
会議室デビュー日: 2003/11/16
投稿数: 1190
お住まい・勤務地: センガワ→ムサシノ
投稿日時: 2007-07-11 10:20
つけないに投票しました。。。が

引用:

じゃんぬねっとさんの書き込み (2007-07-11 09:47) より:

ところで、今さらの確認ですが "付けない" に投票された方は、こういったものさえ 「this を付けない」 から "付けない" に投票されているのでしょうか? 私はプロパティ アクセサの件があるので 「付けたり付けなかったり」 に投票しました。

あっ確かにプロパティアクセスのときは this をつけますね。
プライベートフィールドにも付けるし、付けないのはメソッドぐらいかも。
_________________
かるあ のメモ と スニペット
Error401
常連さん
会議室デビュー日: 2007/03/12
投稿数: 39
投稿日時: 2007-07-11 12:01
いくつかの発言を読み返して思ったんですが、どうも既定のものを含むプロパティやフィールド、メンバ変数、ローカル変数、仮引数などの名前に、同じものを使いたい人が多く、その人たちがthisを付けたいと思っているのではないかと考えます。

nameはどこでもnameだし、heightはどこでもheightでしょう？という考え方ですね。
そう考えると、それもそうだよなぁという気がしてきました。
よねＫＥＮ
ぬし
会議室デビュー日: 2003/08/23
投稿数: 472
投稿日時: 2007-07-11 13:08
引用:

じゃんぬねっとさんの書き込み (2007-07-11 09:47) より:
ところで、今さらの確認ですが "付けない" に投票された方は、こういったものさえ 「this を付けない」 から "付けない" に投票されているのでしょうか? 私はプロパティ アクセサの件があるので 「付けたり付けなかったり」 に投票しました。


たしかに投票された方の前提条件(というか想定している内容)は確認したいですね。

(1)「付ける」という方はthisが付けられる場所は全部付けるのでしょうか。
　(コントロール、インスタンス変数、メソッド、プロパティ、etc)

(2)「付けない」という方はthisを付けざるを得ないところ(及び自動生成コード)以外は一切付けないのでしょうか？

(3)「付けたり付けなかったり」という方の中に基本付けない派なんだけど、
必須で付ける必要のある場面があるので、これに投票した、という方が含まれていたりしないか。
　また、どんなときに付けて、どんなときに付けないか？

＃とネタだけ振ってみる。

--
話が変わりますが、
このスレッドでは基本的にC#の話題なので、
今までVBの場合は？というところの話は控えていたのですが、
VBの場合、以下のようにインスタンス変数、プロパティを同名にはできません。

コード:

Public Class Test

	Private name As String



	Public Property Name() As String

		Get

			Return Me.name

		End Get

		Set(ByVal value As String)

			Me.name = value

		End Set

	End Property

End Class



--コンパイルエラー--

error BC30260: 'name' は、この class で 

'Private Dim name As String' として既に宣言されています。


この辺の背景は私がプレフィックス案を押す一因になっていると思います。
(C#では大文字小文字を区別するので、インスタンス変数とプロパティも同名にできます。
Javaの場合は基本はsetter/getterですし、大文字小文字を区別するので問題ありませんね)


[ メッセージ編集済み 編集者: よねＫＥＮ 編集日時 2007-07-11 13:11 ]
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2007-07-11 15:55
ここまでのまとめ。
異論や誤りがあれば突込みをお願いします。

■前提
業務での多人数開発を念頭に置く。個人で書くぶんには好きにすればよい

主に変数についての議論。メソッドのstatic/インスタンスの別については深く議論されていない

インスタンス変数の扱いは、クラスの状態遷移である。
十分に気をつける必要があり、注意喚起のために目立たせる必然性がある。
マルチスレッド下ではインスタンス変数は特に同期について気をつけなければならない。
なお、static変数の扱いはさらに重要であり、より気をつけるべきだし、目立たせるべき。

ウザイというのは目立っていることの裏返しであり、効果の現われともいえる。

上記は開発者の感じる「ウザイ」といった感性に優先される。
生産性が落ちないのであれば、ストレスのかからないコーディングスタイルがよい

thisをつけるスタイルでも、つけないスタイルでも、特有の記述ミスによるバグの発生は存在しうる。
高機能なエディタである場合、そういったバグを検出できる場合もある。
また、比較的起こしやすく、かつ、検出困難で経済損失が大きいと認められる記述ミスに起因するバグ以外は
どちらのスタイルが良いという判断においてはあまり重要とならない

■命名について
インスタンス変数のハイディングについて
thisで区別すればよい派
→ 言語の標準機能を使うべき
命名は単純であるべき。人間の手でプレフィックスをつけるべきではない (感性による問題？)
命名規約でプレフィックスをつけて対応すればよい派
→ （規約が徹底されている前提において）違う変数であることが明確に分かる
thisの記述漏れによるバグへの対応（高機能IDEでは検出できるので問題とならないのでは？）

■貧弱なエディタにおいて
1) thisの記述漏れによるバグの可能性
2) プレフィックスよりthisの方がキーワードハイライトはしやすい
3) 全てにthisをつける/つけないおよび、プレフィックスをつけることが困難
4) 自動補完などもなく、thisの記述は面倒。記述したとしても得られるメリットが少ない

■高機能なエディタにおいて
1) thisの記述漏れによる自己代入は検出して警告させることができるので問題とならない
2) 構文解析によるハイライト機能でインスタンス/ローカルのカラーリングが可能なのでthisのハイライトしやすいメリットは薄れる
3) プレフィックスが独自の命名ルールであるのに対し、thisは言語での機能なので誰が見ても理解できる
4) 機械チェックにより全てにthisをつける/つけないおよび、プレフィックスをつけさせることが可能
5) thisを入力することによる自動補完が便利。これにより自然と記述するのでは？

■教育的観点において
1) 新人の教育において、暗黙の挙動を理解させるのは大変である。
特定のケースで省略できるという挙動を理解させるより、省略させないほうが理解が早いのではないか？
2) 新人の教育において、ローカル変数、インスタンス変数、static変数の違いを理解させるのは大変である。
thisを省略させないことで、インスタンスについての理解を早める効果があるのではないか？
3) レヴューにおいて、クラスの状態遷移という重大事項を目立たせておくことは効果がある
4) 大人数のプロジェクトでは技術レベルがまちまちである。新人など技術レベルの低い者への配慮は欠かせない

■強調の効果について
重要なものを目立たせるのはよいが、すべてにthisをつけるとかえって目立たなくならないか？
→ そもそも目的に合致した正しいスコープの変数が使われているのであれば
インスタンス変数はそんなに多くはならないはずだ。
問題が起こるとすれば、そもそものクラス設計に問題があるのではないか？

■疑問点
C++では通常thisを書かないのはなぜか？
れい
ぬし
会議室デビュー日: 2005/11/01
投稿数: 346
投稿日時: 2007-07-11 16:13
引用:

nagiseさんの書き込み (2007-07-11 15:55) より:
■疑問点
C++では通常thisを書かないのはなぜか？


たぶん以下の2点。

Cに無いから。
初期のC++に無かったから。

C++はCの拡張で、Cはイニシエの言語ですから。
thisかかないお手本がたくさん転がってたら自然と書かなくなるし、
CでもC++でも動くコードにはthis書けないし。
そもそも昔はthis無かったし。
ソースコードの容量がもったいなかったっていう可能性もあるな…。

最近はC++でも全部に書いているソースをよく見かけますね。
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2007-07-11 16:42
引用:

nagiseさんの書き込み (2007-07-11 15:55) より:

C++では通常thisを書かないのはなぜか？

そういえば C++ をやっていた頃はほとんど付けていませんでした。 this ポインタは自分自身をどこかへ返したりする場合、演算子のオーバーロードなどで使いました。

C++/CLI では普通に this を使っています。 何か自分でも少し不思議ですね。 インテリセンス依存症になっているのではないかと心配になってきました。

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
NABE
会議室デビュー日: 2007/07/11
投稿数: 2
投稿日時: 2007-07-12 00:58
thisは余り付けない方。
少なくとも「thisを付け得る場面では漏れなくすべてに付ける」とはしていない。
その一方で「何としてもthisを付けずに切り抜ける」ともしていない。

「this.Foo」とあると、何となく、何故か、
「インスタンスの外部からもアクセス可能なメンバに内部からアクセス」っぽく感じる。
「Foo」が公開メンバならthisで修飾しても余り抵抗を覚えないが、
「Foo」が非公開メンバだと何となくthisで修飾するのに抵抗を覚える。

インスタンス・フィールドには接頭辞「_」を付けている。
なお、（インスタンス）フィールドは原則privateとする。

言語機能で見分けられるものを命名規則で見分けることが悪ならば、
http://msdn2.microsoft.com/ja-jp/library/ms229043(VS.80).aspx
クラス ライブラリ開発のデザイン ガイドライン/名前に関するガイドライン/大文字の使用規則
> 複数の単語で構成されるパブリック メンバ、型、および名前空間の名前には、常に Pascal 形式を使用してください。
> パラメータ名には Camel 形式を使用してください。
なども、例えば、全部Pascalに揃えるとかした方が良いのかな。
«前のページへ 1|2|3|4|5|6|7|8|9|10|11 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）