- PR -

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

投票結果総投票数:259
付ける 99 38.22%
付けない 66 25.48%
付けたり付けなかったり 94 36.29%
  • 投票は恣意的に行われます。統計的な調査と異なり、投票データの正確性や標本の代表性は保証されません。
  • 投票結果の正当性や公平性について、@ITは一切保証も関与もいたしません。
投稿者投稿内容
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2007-07-09 17:15
引用:

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

nagiseさんの書き込み (2007-07-09 14:17) より:

もっとも、今の時代だとアンダースコアをつけるとかつけないとかも機械でチェックできてしまうので、そういう意味でも、感情的な理由以上に反対するうまい理由を挙げれません。何かひっかかるので論理的な理由があるのかもしれませんが、出てこないので保留ということで。


たとえば、静的なメンバにアクセスする場合はグローバル解決演算子を使ったりして、明示的に分けている言語 (C++/CLI、PHP... etc) もありますが、これはこれで意見が分かれると思います。 そしてこれもやはり感情的な理由が大きいと思います。


static側の変数の参照にしても、stataic側は大文字アンダーバー区切りの命名と
いったように命名が明らかに異なるプロジェクトにおいては問題になりませんし。
細かく前提条件をケースわけして考えないと宗教戦争になってしまいそうですね。

囚人氏が書いていた件
コード:
private int hoge;
public void hoge(int hoge) {
  hoge = hoge; // ←thisがついていないので自己代入になっているというバグ
}


についても、JavaのIDEであるEclipseでは警告が出るので実は実務上は問題にならない。
でも、テキストエディタで開いた場合などにはスルーしてしまうところでしょう。
このあたりも前提によってそれを問題とみる/みないが分かれるところだと思います。
なちゃ
ぬし
会議室デビュー日: 2003/06/11
投稿数: 872
投稿日時: 2007-07-09 17:22
どうも言いたいことを誤解されているようなので…

nagiseさんのおっしゃるような状況では、そのルールは合理的だと思いますよ。
いついかなるときも、うざい、くどいを優先すべきなどとは思っていません。

ただ、それも環境に拠る話だということです。
うざい、くどいというのは単なる気分の問題だと思われているようですが、
thisを明示することによるメリットと、開発者がうざい、くどいと
感じる状況で開発を行う場合のミスの発生率、開発効率の悪化等、
デメリットについて正確な統計がありますか?

私の思っている、うざい、くどい、というのは、プログラムの読みにくさに
直結しているという認識であって、ただの気分の問題ではありません。

それから、ルールを守らない、あるいは明らかに合理的なルールに対して
文句を言っているわけではありません。
どうも開発者のいうことをコケにしてませんか?
(開発者は気分でただめんどくさいから文句言うだけと思っていませんか?)
ぶさいくろう
ぬし
会議室デビュー日: 2005/11/22
投稿数: 1232
お住まい・勤務地: 川崎市(は俺も含めてロクな人間が住んでないよw)
投稿日時: 2007-07-09 17:41
引用:

なちゃさんの書き込み (2007-07-09 17:22) より:
どうも言いたいことを誤解されているようなので…

nagiseさんのおっしゃるような状況では、そのルールは合理的だと思いますよ。
いついかなるときも、うざい、くどいを優先すべきなどとは思っていません。

ただ、それも環境に拠る話だということです。
うざい、くどいというのは単なる気分の問題だと思われているようですが、
thisを明示することによるメリットと、開発者がうざい、くどいと
感じる状況で開発を行う場合のミスの発生率、開発効率の悪化等、
デメリットについて正確な統計がありますか?

私の思っている、うざい、くどい、というのは、プログラムの読みにくさに
直結しているという認識であって、ただの気分の問題ではありません。

それから、ルールを守らない、あるいは明らかに合理的なルールに対して
文句を言っているわけではありません。
どうも開発者のいうことをコケにしてませんか?
(開発者は気分でただめんどくさいから文句言うだけと思っていませんか?)



いくらなんでもそれはないと思うし。コケにしてないかのくだりはさすがに言いすぎじゃまいか・・・
冷たい言いかたをすれば「くどい」「うざい」だけならそう捉えられても仕方ないと思うな。
本当に改善したいなら明確な理由をつけた言い方にするというのもそうだが。
「くどい」「うざい」ってのは気持ちから発する言葉で上の人間はそこまで読めないんじゃないかな。
読むべきだという意見なら止めはしないが。開発者あがりでも難しいじゃないかな。
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2007-07-09 18:03
引用:

なちゃさんの書き込み (2007-07-09 17:22) より:

nagiseさんのおっしゃるような状況では、そのルールは合理的だと思いますよ。
いついかなるときも、うざい、くどいを優先すべきなどとは思っていません。

ただ、それも環境に拠る話だということです。


私の言う環境では合理的だと認められていますよね。
では、合理的ではない環境というのはどういう環境なのかを述べてください。

なちゃ氏の続く節が
引用:

うざい、くどいというのは単なる気分の問題だと思われているようですが、
thisを明示することによるメリットと、開発者がうざい、くどいと
感じる状況で開発を行う場合のミスの発生率、開発効率の悪化等、
デメリットについて正確な統計がありますか?

私の思っている、うざい、くどい、というのは、プログラムの読みにくさに
直結しているという認識であって、ただの気分の問題ではありません。


というように先に述べた「合理的」なケースではない場合の話ではなく、
常にthisなんて付いていると読みにくいと主張しているように思われます。

統計データが無いからthisをつけるほうがよいという説は無効だ!
thisなんて付いていると読みにくいんだ!統計データはないけど!
という主張に読めるのですが(そんな幼稚な主張ではありますまい)
本意はなんなのでしょう?

引用:

どうも開発者のいうことをコケにしてませんか?
(開発者は気分でただめんどくさいから文句言うだけと思っていませんか?)



私がその開発者の筆頭です。
プログラミングなんてしたこともない人間が統制をとっているようなシチュエーションでも想像されましたか?

開発者だからとかそんなことは抜きにして人間、単純に面倒なことは嫌いなもんです。
では、どうすれば面倒が少ないか、そんなことを考えながら開発をしているわけです。
面倒だからで質が低下したら、トータルではもっと面倒なことになるでしょう?
システム屋なんだからシステムをうまく使ってそこのバランスをどうとろうか?と
建設的に考えることが大事だと思っています。

引用:

どうも言いたいことを誤解されているようなので…


誤解部分を明示してください。議論において前提のすりあわせは重要です。
なちゃ
ぬし
会議室デビュー日: 2003/06/11
投稿数: 872
投稿日時: 2007-07-09 18:03
んー、すみません、確かにちょっと言いすぎでした。

引用:

医療現場では薬品の取り違え対策でカラーリングをしたりしているわけですね。
こういうのって根性論じゃ駄目なんですよ。
根性でよく確認すればインスタンスなのかローカルなのか分かるだろ!


ちょっとこの辺に反応してしまいました。
そんなことを言ってるわけではない、というのが言いたかったのでした。

引用:

「みんなでプログラム」する場合にどういうルールが合理的?という観点で考えて貰いたい。


これもthisをつけるのが合理的であり、つけないのは不合理だと言い切っているように見えたので、それも主観ではないですか?といいたかったのでした。

うざい、くどいは、そうですね、どちらかというと、言葉ではそんな言い方でも、
実際には読みやすさ、というようなことを含めて言っている場合が多いのでは?
という感覚で書きました。

もちろん、例えばコメントなんかなくてもいい、とか、そういうので必要なコメント
書くのまでうざい、くどいなんて言う人がいれば、それは、ただのめんどくさがりの
可能性が高いと思うんですが、今回はthisをつけるかどうかの話です。

これまでの感覚として、thisをつけない、という人が、ただめんどくさいからとか、
ルールを守れないとか、合理的に考えられないとか、そういう人だったかというと、
それは違うことの方が多かったように感じます。

まあこれも主観なので、確かにちょっと無茶を言った感じはします、失礼しました。
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2007-07-09 18:50
引用:

なちゃさんの書き込み (2007-07-09 18:03) より:
引用:

医療現場では薬品の取り違え対策でカラーリングをしたりしているわけですね。
こういうのって根性論じゃ駄目なんですよ。
根性でよく確認すればインスタンスなのかローカルなのか分かるだろ!


ちょっとこの辺に反応してしまいました。
そんなことを言ってるわけではない、というのが言いたかったのでした。



その引用の仕方はちょっとやめて欲しいですね。
引用:

医療現場では薬品の取り違え対策でカラーリングをしたりしているわけですね。
こういうのって根性論じゃ駄目なんですよ。
根性でよく確認すればインスタンスなのかローカルなのか分かるだろ!
って言ってしまうとそこで対策はおしまいになってしまう。



太字部分が主張です。
根性論で確認なんて私は嫌です。
では、誤認しない方法は何?っていう話です。
もし、「誤認とか関係ないんだよ、ウザイものはウザイ、読みにくいんだよ!」と
おっしゃるのであれば、「そんなことを言ってるわけではない」という主張でよいと思います。
ただ、私からの単にウザイという話題ではなく、現実問題、そういうものとの
バランスで考える必要があるよね?という提案です。
そうしないと単にプロジェクトとかそういう社会を無視した主張にしかならないでしょう?

私は「this付ける派」ですが、thisをつけないほうが合理的なんだという
納得できる理由があればいつ鞍替えしても構わない。
より誤認しにくい書き方は何?ということについて話題にしようとしたのでした。
私の表現が稚拙ゆえに誤解を招いたようであれば申し訳ないと思います。

引用:

引用:

「みんなでプログラム」する場合にどういうルールが合理的?という観点で考えて貰いたい。


これもthisをつけるのが合理的であり、つけないのは不合理だと言い切っているように見えたので、それも主観ではないですか?といいたかったのでした。


私の主張はthisをつけるほうが合理的というものです。
その論理的な理由はこれまでに述べてきました。
論理が示されずに「thisをつけるほうが合理的」と言っているのであれば
主観とのそしりを受けても構いません。
そして、そうなのだとすれば、今後改めたいと思います。
なちゃ
ぬし
会議室デビュー日: 2003/06/11
投稿数: 872
投稿日時: 2007-07-09 23:03
どうも、なぜか私が、

・プログラムの誤読の可能性が増えても面倒でないほうがいい
・個人でプログラムするときのことを考えていてみんなでする場合の合理性を考えていない
・ルールを守るのが面倒くさいというのを正当化している
・根性論で、よく見れば分かるようなことは無駄だと思っている
・thisがついているのは絶対的に読みにくいと主張している
・nagiseさんが根性論で確認と主張していると思っている
・thisはつけないほうが合理的だと主張している
・nagiseさんが理由を述べずに主張していると考えている

てな風に思っているように受け取られているような感じなんですが、
そのように思われるようなことを何か書きましたかね…?
※まあこんな風に書くのもどうかとは思いますが。
どうも誤解されているように感じます、というかそれほどのことを何もまだ書いてないつもりです。
ぜんぜん違うということなら私の方が誤解ですが。


とりあえず、thisをつけて誤読が減ることがメリットであるなら、thisをつけないでたとえばプレフィックスなどで明示するのもそれなりの同様の効果があり、
thisが煩雑に見えてコードの本質が読みにくくなる、と感じる人間がいることも事実であり、
まあ要するにどっちが正しいとかどっちの方が絶対的に合理的なんていうことはなくて、
対象とする開発者やそのレベル、人によってどの程度のやり方が合理的かは変わるという
ただそれだけのことを言いたかっただけです。

うざい、くどい、というのは理由になってないように見えますが、
実際には可読性やら何やらで、しっかりデメリットになってる面もある
ということではないか(一概に、うざい、くどいなんて理由にならん、無視
としていいものか)
※最初からこんなこというやつは論外、話にならん、無視、と
 決め付けているように「見えた」のです。

なんとなくnagiseさんが、thisをつけるのが絶対的に合理的である、
thisをつけないのは頭から不合理である、といっているように見えてしまったわけです。
※繰り返しになりますが、逆が正しい、といっているのではありません。


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

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

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

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

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


[ メッセージ編集済み 編集者: なちゃ 編集日時 2007-07-09 23:14 ]
まりも
ベテラン
会議室デビュー日: 2006/08/19
投稿数: 77
投稿日時: 2007-07-10 00:02
自分にはthisをつけないほうが可読性が上がるような気がしてならないのですが、その理由を考えてみました。

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

ソースを読む時ってのは、どういう機能を実装するかを考えることがメインとなるべきものだと思います。
何をするのか、適度に抽象的に書いてある、変数名やメソッド名を一生懸命読むのが理想だと思います。

と言うあたりを理想のソースだと思っていると。
thisとかは、確かに重要と言えば重要なんですが。
常に注釈としてつけるのは、帰って分かりにくいと思うのです。

細かいことまでいちいち全部書いてあるのがわかりやすいというものでもないでしょう。
雑多な情報が全部書いてあるとかえって見にくくなることもあります。

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

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

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

メソッド内変数は、メソッドを細かく細分化すれば混乱することもないです。


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


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

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