いやほんとに。見てるこっちが切ない。
可哀そうで仕方ない
for の括弧の中での演算子
俺は演算子の前後にスペースを入れない書き方が大嫌いなんだけど、for の括弧の中では例外的にスペースを入れないようにしていた時期があった。なんとなくまとまりのあるほうがいいかなぁって思っていたから。
でも最近 Javascript で var をちゃんと使うようにしてからはその変則的なルールをやめた。
for (var i=0; i<100; i++)
alert("pgr"); for (var i = 0; i < 100; i++)
alert("pgr"); var の後にはスペースがもちろん必須なわけで、そのあとに続く部分でスペースを空けないと var だけが浮いてしまう感じに見える。気持ち悪いのでスペースをあけるようにした。var とかない C でもスペースをあける。ほとんど同じ文法なのにスペースあける場所が違うとかは論外だからね。
pre, code の色づけ
Color code のリファクタリング (というほどでもない)
やっぱり遅いので処理を見直し。なんだけどあんまりできそうなところがなかった。ちゃんとプログラム書ける人が見ればありそうだけど。
StringScanner 内 scan メソッドの無駄処理。作ったときから気になってた部分。scan メソッドはかなりの回数が実行されるので改善すればそれなりに効果があるはず……だけどあんまり変わらなかった。
// #改善前 2回正規表現マッチさせてる
var m = this.string.substring(this.pos).search(regexp);
if (m == 0) {
m = this.string.substring(this.pos).match(regexp);
// #改善後 一発で
var m = regexp.exec(this.string.substring(this.pos));
if (m && m.index == 0) {
ECMAScript の仕様を読み直してみたら Regexp.prototype.exec はマッチした位置をちゃんと設定してくれるらしい。はやく気付けと。
このスクリプトで有利なのは Opera8.5。実行途中でもちゃんとスクロールが効くし、上から順番に色が変わっていくのがわかる (遅いマシンでもストレスを感じない)。ただし速度は最悪。対して Firefox や IE は速度は Opera の数倍だけど実行中完全にブラウザごと固まる。ブラクラ候補。
かかった時間を pre や code の title 属性に入れてみることにした。[Time-Spend:66ms] とか出るよね？ Perl がもっとも遅い (例のページの Perl の部分が Opera では10秒近くかかる)。なぜなら正規表現の数が多いから。同じクラスのやつを一つの表現にまとめれば早くなるだろうけど可読性が最悪中の最悪になるので見送り。
XML と Io はそこそこはやい。これは両方とも正規表現の数があんまりないから。XML はそれに加えて /[^<>\s]+/ を OTHER として読み飛ばしているのでループ回数が減ってる。
つーか、こんなことしなくても普通に正規表現だけかけて置き換えすればいいじゃんって話な気がしてきた。だめだこれ。