かっこの話
例えばif文やfor文の括弧。
(1)『if (Hoge)』
(2)『if( Hoge )』
視覚的な効果でいうと、(1)は命令文が見やすくなり、(2)は内容が見やすくなる。
見やすくというよりは見分けやすくだろうか。
エディタが白黒の頃であれば(1)は有効だった。
「if」と「Hoge」は同じ色で表現されるため、
まず言語のもつ命令文や、自作のクラスやメソッドがなんであるかを見分けられることは
プログラムを理解する上では、とっかかりが楽になる効果が期待できた。
しかし、エディタがカラフルになった昨今。
言語のもつ命令文は色分けされるようになった。
括弧と色が違う文字である命令文はくっついていようが離れていようが識別がたやすくなったのである。
ここに「if」と「Hoge」に明示的な差ができたのである。
OOPであればまだある。
状態判定用のメソッドを持つ場合や、equalsメソッドを使用する場合など、
括弧内が基本データ型だけではない状況が増えた。
例題では判断材料が足りない状況が出来たのである。
equalsで例題を作り直してみる。
(10)『if (Hoge.equals(Hage.toString()))』
(20)『if( Hoge.equals( Hage.toString() ) )』
構文を把握するために必要な時間を考えたときに、少なくて済むのはどちらだろう？
「if」の発見、「Hoge」の存在を発見、「Hage」との区別、括弧数の個数チェック・・・・・などなど。
それらのチェックポイントを設けてシュミレーションを行えば答えはでるだろう。
人体特性をかじってみる
人の目には特性がある。
同じ色の文字列の中にある特定の文字を探すよりは、
同じ色の文字列の中にあるスペースを探すほうが楽に発見できる。
スペースには色がないから識別しやすいのだ。
この認識をもとに(10)(20)を判断すると
(10)では「(Hoge.equals(Hage.toString()))」に注目することになる。
・equalsとtoStringの見知った文字列を検知
・カッコを元に構文の区切りを探す
・それに伴いHogeとHageを認識
・範囲内にある全文字列の役割を解析
・構文を理解
このような思考経路をおいらは辿る。極力特殊な反応しないように考えてみている。
それに対して(20)ではこうなる
・スペースを追う
・3つくらいのブロックがあることを認識
・ブロックにそれぞれequalsとtoStringの見知った文字列を検知
・HogeとHageが何者であるかを気にせずとも構文を理解できる
4番目が大事。
(10)では全文字列を解析する必要が出るのに対して
(20)では特定の文字列のみで結果が出せることがあるのだ。
何度も見るソース。
何度も確認する構文。
１回にかける時間は短いほど早く完成に近づける。
質を落とさずにという特典つきでである。
これは利用しない手はないだろと思う。
１文字変数の話
規約にはサンプルソースが掲載されている。
なんで多くが1文字変数なんだ？
これはおばかな教科書か？
これはプログラマへの呪いか？
真似したら100%余計な苦労すると断言できる行動も珍しいが
１文字変数や１文字メソッドは間違いなく悪だと言い切る。(゜Д゜#)
かつて呪いをかけられた者の1人としては、断ち切るための苦労は別のところに向けたかったと思うぞ。
ループカウンタを「i,j,kを使う」と言い切ったそこのお前ら！
メリットはなんだ？
使用することを推奨するからにはなにかしら利点があるんだろ。
それを一度でいいから聞かせてくれ。
「開発者が開発時のみに記述しやすい」
これだけしかねーのならそれは非効率だとオレは言い切るっ(゜Д゜)
なお、結論までの経路はこちら。
（参照：1文字変数再び ついでに1文字変数）
とりあえずプログラムのロジックを作る者としては、
理がないことをする理由はない。
常日頃から楽をしたいと願う者としては、
楽できない状況に自らハマりたくもない。
1文字変数を毛嫌いする理由はこれで充分だろ。
きっと。ヽ(´ー`)ノ
