マイナーな日本国内のMMORPGなら日本語のみでチャットできるので
挨拶とか
＊＊＊って武器っていくら？とか
＊＊＊行きたいです！とか
などの日常会話には苦労することがない。
実際には『効率厨』が多いので、『募集！＊＊＊クリア経験者求む』をよく見かけるし、外人も『（ベテラントレード）』(元々はApproachのヒット範囲を広げる漁師のアクション)などと云っているのでそう変わりない。
当然、本当の日常会話なら、何も問題ないと思っていたら・・・そうでもなかった。
- 最速
- 最適化
- 保守性
この意味が実は違っていた。
最速と云えば、
まず仕様からどうなのよ？
と、考えないといけないと思うんだけど、そんなことはナシで、
文字列の足し算 よりは StringBufferが良く、 欲を云えばスレッドセーフではないStringBuilderが最高！とか、ドコの板のREなのか？と思えるような話だったりする。
本音を言えば、それくらいコンパイラかStringクラスの中で隠蔽出来ないのか？と思える内容だ。そんなコトを云ってもコンパイラを直せるハズもなく、ソレを使うしかないというのも、情け無い話。でも、性能が出ずタイムアウトするならヤルしかないよね。（大笑）
その点、MFCのCStringは結構がんばってた。
最適化の方は、
例えば、短い文字列なら、文字列の足し算でもいいじゃないか。
ここまではいい。
しかし、似たような処理（関数と云ってもいいしメソッドと云ってもいい）をコピペして使うなら・・・
一斉に修正しないとマズい！なんてことはコピペにはよくある話でStringBuilderを使っている所をワザワザ文字列の足し算に書き換えない方が無難だ。
※もし、
String text = “abc” +
“def” +
“ghi”;
なら、変更は簡単で、
StringBuilder text = new StringBuilder();
text.append(“abc”);
text.append(“def”);
text.append(“ghi”);
なら、変更は難しいと思うなら、
abc
def
ghi
を 正規化の置換で 変換元 ^(.+)$ 変換後 text￥.append(￥1) みたいにすれば どっちも簡単だったりするし、元のテキストに戻すのも、変換元 ^[ ]+text￥.append￥((.+)￥)$ 変換後 ￥1 とかで どっちも一発で戻るんじゃないかな？要は簡単に変えれるように注意深く書くことだろう。
だから、ボクは
String text = “”
+ “abc”
+ “def”
+ “ghi”
;
あたりが一番楽だと思っている。
SQLなら
select
T1.Abc as abc
,T2.Def as def
,T2.Ghi as ghi
from
TABLE1 T1
,TABLE2 T2
where
T1.Abc = T2.Abc
and T2.Def = ?
な感じだろうか・・・
カンマを手前に書くのは書き忘れたら気が付きやすいからで、それに習ってandも同様、なぜ予約語を小文字で書くかと云えば、いつも書くし場所も大抵決まっているので小さい文字で十分だからだ。どちらかというと出現頻度の少ない単語の方が大文字小文字を混ぜて書いたほうが見やすいが、何かのツールでSQLを書いているなら、あえて、大文字小文字とかエイリアスとかは書き換えない、どうせミスったら何度も綺麗に手直ししなければいけないからだ。
だが、本音を言えばO/Rマッピングで十分だと思ってる。
しかし今は、短い文字列なら、文字列の足し算 に書き直すのが最適化（つまりエレガント）であるらしい。
もし、中身が増えたり、実はループの中で１００回くらい出現するかも？なら、StringBufferの方がよろしい！という様に調整（書き直し）するのが美しいらしい。
類似例には、『ループが確実に一回ならwhileはifにしなくてはいけない』があるが、これも、２～３回 if とwhile を往復したり、ヒストリーを見てたりするとそうだったりしたなら、
while のままで良くない？って感じもするが・・・
そう思うのは『遠い未来』かもしれないし、そう思うこと自体が（ドツボの）経験の差かもしれない・・・
経験的には、if から while への変更が必要なら書き換えるしかないが、よ～く考えたらifで十分だったなら、そのままがいい。
そして最後は保守性、
沢山のソースがあったら、似たような書き方の方が後々見るのが楽なハズ。（この辺のコンセンサスはOK！）
でも、
onClick=” document.***.submit ”
って書くあたりは単純に美的感覚の違いなんだろうな？
面倒くさいからコレでいいや！ってならOKなんだけどさ。
もうね・・・
j-Queryっぽくガリガリと初期設定しまくった方が保守性高いんじゃない？
って気がしました。
でも、ボタンが１０００個もあるならj-Query式設定はきついよね。
まぁ、周囲と年齢が、かなり離れてしまっているので、
・・・
価値勘のズレが結構あるってトコロが本当のところかもしれない。
そしてそう云うときは若い方にあわせたほうがマシだと思ってる。
なぜなら、前述の様に古い価値勘を説明する単語自体が意味が変ってたりするから、説明するには多くの事例を引き出してこないといけないし、更に今風にアレンジしないと「今はそんなことないですね。CPUもメモリもG単位ですから」と思うはずだからだ。
もっとも先の文字列の足し算はG単位だから昔より酷い目に遭うのだけどね・・・