はじめてのにき(2016-08)

あまり人の書いたものについてどうこう言いたくないし言ってもしょうがないし、飲み会で言うとかはともかくわざわざ書いたりもしないのだけど…もやもやするので言いたくなってしまった。別に自分のアプリで使ってるとかならどうでもいいんだけど、ruby gemになっちゃってるあたりと、なんとなく見てみるとはてぶたくさんついててかつ誰もコード読んでないぽいあたりで、もやもやが。特に後者

https://github.com/k0kubun/hescape

きちんと確認してないので、間違ってることもあるかもしれないです、が、一番ウーン、、、とおもった点を書いていきます。間違ってることがあると申し訳ないですが

const uint8_t* src と size_t size を受ける関数に関わらず、 src[size] == NULL であることを仮定している。 cruby では正しい前提ぽいんですが、かなり悪いインターフェイスだと思う。https://github.com/vmg/houdini はたぶんこの問題を持っていない
uint8_t* のインターフェイスについて何も伸べていない。 ruby >= 1.9 でかつ SJIS とか使ってるとたぶん即死ですよねこれ https://github.com/vmg/houdini はちゃんとUTF8以外サポートしていないと明示している
https://github.com/k0kubun/hescape/commit/e04b6f8c4a60c765f2eaf78f409b6f3d6ecef27c のパッチを受け入れた。これ一般的なケースで遅くなる気がして、実際僕の手元では遅くなってるし正直やらない方がいいという感覚が強い

ここからはより主観的かつnitpickな項目が多くなっちゃうのだけど、以下のような理由で上記のような点を修正すればOK、という気持ちになりにくいなあ…と思った

Round allocation up to multiple of 8. というコメント。コメントは何をしてるか、より何故これをしてるか、を書くべきで、このコメントは何故これをしているかが説明されてない。その上でバッファを1.5倍してるコードはまあわかるんだけど、こっちは意図がわからない。この問題は https://github.com/vmg/houdini からコードをコピペしたから起きてるんだと思う
append_ ではじまる二つの関数の引数が理解しづらい。これのおかげで未だに現在のコードのセマンティクスが正しいと確信が持てないでいます
実アプリでテストしてる気配がない。個人的な意見だけどトレードオフのある速度最適化はちゃんと速くしたいものがある時にやるべきかなと。
テスト/ベンチのテストケース少なすぎ
*bufにmallocしたバッファを返すというインターフェイスなのだけど、これがmallocされたものかどうかは返ってきたサイズを見ないとダメで、それがドキュメントされてないのはイマイチな気がする。まあrubyの方では適切に処理されてるぽいから良いのでしょうけど
あとfind_escape_fastの修正の仕方も気にいらないというか、変化してる変数が3つになってて正直わけがわからない(←これは完全にウソでした…コメントに書きます)

あとなんだろう。HTML_ESCAPE_TABLEていうデータがあるんだけど、これ本当に速いんだろうか。。とか、気になることはまだあった気がする

(14:28)