トップ «前の日記(2005-03-29) 最新 次の日記(2005-03-31)» 編集

日々の破片

著作一覧

2005-03-30

_ 三項演算子がわかりにくいという伝説

たとえ三項演算子が好きでも、チームが分かりにくいと感じたなら、使わない。

コードがドキュメントだ(マーティンファウラー)

また妙なことを言い出す親父めが。

というくらい、この妙な伝説を目にする。オブジェクト倶楽部のコーディング規約にもあったような気がするな。

では、質問だが、三項演算子がわかりにくいと感じた人って実際にいるのかどうかだ。わかりにくいと感じますか?

いや、おいらは感じないが、きっと感じる人間がいるはずだ、ってのは無しにしておこう。だいたい、自分はわかるが他人はわからないという考えは傲慢というものだ。

たとえば、COBOLやVBにはそういう演算子は無いから、彼等にはわかりにくいということなのか? でも、そんなこと言い出したらclassとかinterfaceとかどうするつもりなんだろう。今時はあるからいいのかな? でもinterfaceはないぞ。

そうか、わかった。interfaceはわかりにくいから使うなということですね。本当にそれで良いのか?

むしろ、こういうのはどうだろうか。

たとえ正しい英語のフルスペルが好きでも、チームが分かりにくいと感じたなら、使わない。ローマ字(内閣訓示式なら小学校の教科書にも表が出ているからより良い)を好め。

ローマ字だから、masinn(マシンのこと)、buluu(ブルーのこと。本当はアクサンシルコンフレクスみたいなマークを使うべきだけど無いから重ねる表記法(これも正当))、konpyuutaa(コンピュータのこと)とかでコードを書いてくださいね。

追記:

もっと良い例が見つかった。

たとえ単項演算子++や--が好きでも、チームが分かりにくいと感じたなら、使わない。右につくか左につくかで評価順が変わること、VB、COBOL、Rubyといった主要な言語には存在しないことから、最低最悪にわかりにくくバグの温床である。

っていうか、だったらC系の言語を使わなきゃいいだけだろうに……

さらに追記:

プログラミング言語C++でストラウストラップが、条件の部分はifの応用で(文法的には不要だが)カッコでくくれと書いていたが、僕はその書き方が好きだ。

return (condition) ? LOCAL : GLOBAL;とか、int var = (condition) ? GODLEY : CREME;とか。

実際、Javaのように条件がbooleanと限定されていないCとかで、return var1 + var2 * var3 ? var4 + var5 : var6 * var7;とか書いてあれば、それは確かに紛らわしいと思う。多分、真意は結合規則に頼っていて実際の評価結果がわかりにくいものを書くな、という教訓だと想像できるが、それがどっかのおっちょこちょいのために三項演算子だけが槍玉にあげられたんじゃなかろうか。っていうか、return (var1 + var2 * var3) ? (var4 + var5) : (var6 * var7);と無駄でもしろということだけのような。(さらに追記:というか、3項演算が8重くらいにネストしたら、それは読めないだろうということから、単純に量の問題−−メソッドの行数はだいたい50行くらいまでとかそんなやつ−−なのが、黒白はっきり主義者の魔手にかかってしまって全てかまたは無かという選択になってしまったのかも。黒白くっきり主義者は、メソッドが長くなるとわかりにくくなるからメソッド自体の記述禁止とかといった規約を掲げて欲しいものだ。あるいはプログラミング言語は自然言語と異なって人間にはわかりにくいからプログラミング禁止とか。そのくらい馬鹿げた言い分であるな)

本日のツッコミ(全8件) [ツッコミを入れる]
_ (2005-03-30 04:44)

トリグラフ(トライグラフ?)はわかりにくいので禁止してほしいかも。<br>知らないとうっかり書いちゃうんだけどね…

_ Kazz (2005-03-30 07:56)

原文(http://www.martinfowler.com/bliki/CodeAsDocumentation.html)と比べて読んでみると「郷に入っては郷に従え」で行こうぜ、と説く為の単なる例としても読み取れるような気も。<br>それにしても何故三項演算子を槍玉にしたのかな。ファウラー氏も嫌いなのかしら?

_ arton (2005-03-30 09:21)

>咳さん<br>トリグラフは確かにうっかり書いてはまることがありそうですね。<br>>Kazzさん<br> 逆に奇妙な慣習として例にしている可能性もあると思いますよ。

_ かくたに@三項演算子わりと好き (2005-03-30 09:31)

>オブジェクト倶楽部のコーディング規約<br>他にも改訂したほうが良さそうなところがあると思ってて(抽象クラスとインターフェースのところとか)、以前に一度指摘してるんですけど、放置気味ですね……。

_ Classiclll (2005-03-31 10:04)

カッコつきの三項演算子は私も好きです。<br>オブジェクト指向というより、昔で言う「関数プログラミング」指向ベースです。古いとはいえ、オブジェクト指向と衝突するような概念ではないと理解しています。

_ (2005-03-31 12:30)

ことしは、Javaの奇妙な慣習がくるかな

_ unibon (2005-04-03 16:04)

3項演算子は、私は Java だったら使いませんが、C/C++ だとたしかに変数の初期化との絡みで使わざるを得ないと思います。<br>ただ、3項演算子と他の演算子との優先順位の優劣が、イマイチ(私の)直感と違っていて悩んだことがあります。それからは3項演算子を使うときは括弧をたくさん付けるようにしました。<br>あと、3項演算子の評価がいわゆる short circuit だったかどうかがうろ覚になってしまい、これもバグの元になるかも。

_ arton (2005-04-05 21:52)

>3項演算子の評価がいわゆる short circuit<br>それって、<br>i = 0;<br>(false) ? ++i : ++i;<br>の時、?後を評価して結果が2になるかという意味ですか?<br>だとしたらならない(=直観的)だと思いますが。


2003|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|12|

ジェズイットを見習え