今週は、会社のお仕事で、去人にさわる暇なしである。
仕事を早く終わらせて、すっきりして退社するのが、会社での行動原理なので、線表を前倒しにするのが基本だ。
んで、前倒しにしたら、こんどは新しい仕事が入ってくる。
まあ、当然といえば当然である。
仕事の量を増やして、オゼゼがかわらないんだったら…とか昔はよく考えていたんだが、最近はそういうのがあんまし気にならない。
どうやら、プログラミングしてるほうが、楽しいらしい。
好きなのはいいのだけど、もうちょっと、まともな技術があればなぁ…とは切実に思う。
他人のソースコードをみていると、根拠がわからないコードに出会う。
こうした明確な根拠があるのか? と聞きたい。
あるところでは、例外を伝播し、あるところでは抑止してしまう。
事前条件を満たしていないときに、ここでは、処理を続行し、こっちでは、即座にreturnする。
D言語では積極的にassertを使用しているので、この配列中のいずれかには、この値は必ず入っている、というロジックで、それが見つからなかったらassertでひっかかけるようにしている。
実装中ならばjavaのWebシステムでも積極的に使うべきだと思うのだ。
それと、あまりにも人間的すぎるコードがある。
可読性と人間的コードは基本的に同調する。
これは例えの話、ソースをみると殆どの for で
for (int i = 0; i < v.size(); i++ ) {
....
}
となっている。
ソースの多くで、インクリメントは後置となっている。
わたしはこういった、どちらを使っても良い文脈ではクセで ++i とする。
MoreEffectiveC++にのっていた、前置と後置のコストの違いである。
だから、プリミティブ型の変数でも前置にするクセがついている。
わたしの場合は、こういった慣習があるのだけれど、これを知らない人はなぜ、後置か?
人間的だからではないのだろうか?
主語+動詞ではないだろうか。i を 1増やす、というのがコードに翻訳しやすい。
こういった、人間的コードはロジックの可読性をそのコミュニティー内だけで、意味を持たせる。
もちろん、それは有効ではあると思うけど、それだけではやっぱり、見えてこないものもあるとおもう。
翻訳の基本、他の言語を他の言語にロス無しに写像できるか?
(あるいは、私たちのやり方で考えている方式での変更の余地のない「アトム」であったとしても、果たして他の大系でも「アトム」であるか、というようにその可能性も考えておくべきではないだろうか)
まあ、これはたとえ話なので、これをロジックまで拡大解釈できるといいかもしれない。
わたしは、i++ なんて些細なことを突っつきたいわけではない。
コードが人間に近づいてきたのは、歓迎すべきところだし、言語開発者には頭が下がる。
多態とかホントに、うまいことやるなー。