きれいなソースを数値化して欲しいという妄想など

いまの職場はきれいなソースを書いて、コメントを書かなくても何をやっているかわかるのが理想。そのために、識別子の名前を説明調に長い感じで。
・・・という方針でやるということなので（そのことに異存はないので）それに従っているつもり。ただ、最近は、ソースコードリーディングの能力にもばらつきがあるので、ロジック読めばわかるけど、と思いつつ以前よりはコメントを多く書いているつもり。
逆に思えるかもしれないのだが、一般に公開するのであれば、こんなにコメント書かないと思う。

全てはソースコードに書いてあるので、「ソース読め」と言いたいのだが、実際は「ソース読んでください。せめてコメント読んでください。」と言っても、ままならない。
他人のソースを追う（僕の場合は、 find + grep で、だが Eclipse でもなんでもいい）ということを、まったくしないのは、やったことないからやりかたわからないということと、そういうことに価値観を見いだしてなくて「聞いたほうが速い」と思ってるからだと思う。
もはや誰が書いたかわからないプログラムの改修から入った僕は、「他人のソースを読まなくてすむ」環境で職業プログラマーという状態が想像できないのだが、「仕様書もらってその通りに作って終わり。自分の書いた所以外のソースは読まない」というやりかたをしていたとしか思えない。
職業プログラマーは、（自分の書いたもの含めるが）プログラムを「書く」職業でなく「読む」職業でしょ。僕は、書くよりも他人の書いたソース読んでる時間のが圧倒的に多いよ。

「きれいなソース」という基準で判断しようとする時に、好み？とか自己満足の世界なんでは？とかあるので僕の中では、「わかりやすいソース」と微妙に表現を変えている。しかしながら、「きれい」も「わかりやすい」も、言ってることは同じで、最後は好みの問題になってしまうのがエンジニアリングじゃねーなー、と思っている。
ソースコードのきれいさ、わかりやすさを数値化しようという試みは、情報系の大学で研究している人はいっぱいいると思うけど、実際には無理だよなーと思う。

どっかからコピペして使ってない処理みたいなのは、あきらかに削除していいが、名前の付け方のわかりにくさは、突き詰めれば「自分には」わかりにくいというだけなので、動いているものを直させるのは抵抗があるし、直される人はなおさら。
僕は、たぶん「きれいに書きたい派」と「無頓着派」の間にあって、もうちょっとわかりやすく書けよーと思う場合と、そんなにこだわらなくていいよー、と両方思うので、どっちの気持ちもわかる。
結局、最後は「直すべき」「そのままでいい」というのは、自分の好みに帰結すんのかなー、と思うと、他人の書いたソースを「それじゃダメ」というのは躊躇してしまう。


昔は、プレフィックスに１文字か２文字で型を記述するハンガリアン記法が、特定のジャンルでは正義だった。その後、それはシステムハンガリアンと名前を変え、アプリケーションハンガリアンを経てハンガリアン記法は良くないものになってしまった。だから、なんらかの基準を作ってという話はことあるごとに出るが、正義は時とともに変化して、基準はいつか合理的でない程に古くなる場合があることを考えると、基準を作るっていうのは反対だ。
何より僕は、「システムハンガリアン」が、「新しくて良いもの」で、実際にソースコードを読みやすくする記法だった時代にプログラミングを始めたので、「良いソースコードは時代とともに変わる（かもしれない）」と身をもて感じている。

結局のところ、作家がたくさんの本を読むように、ソースコードをたくさん読んでわかりやすいソースとは何か、というのをソースの中から読み取って行くしかないのではないのかなー、と思う。
そして、僕も、わかりやすいソースがどういうのか、まだよくわからないので、いろんな人のソースを読まないといけないなー、と思ってる。

ただ、最近の google の翻訳技術なんかはすごいので、あと 10年くらいたったら、Google コード検索で、「ソースのきれいさ 80%」とか出て、不具合らしき行は赤くハイライトしてくれたりすんのかなー、と妄想する今日この頃。