たかがスペル、されどスペル

他人のプログラムを読むとき、大文字小文字の使い方やインデントの仕方などが自分のスタイルと異なる場合には読みにくいと感じるが、それもでも、一貫した規則によって書かれてればそれほど抵抗感はない。しかし、スペルミスが多いコードを見ると、それを書いたプログラマがどんなに優秀であっても、一気に読む気が削がれてしまう。いや、そのようなコードを書くプログラマが優秀である筈はない。

つい最近、急遽臨時に加わったプロジェクトで、これまで面識のなかった関連会社チームのコードを読む機会があった。その中で重要な位置にあるリーダ格のベテランプログラマが骨格となるフレームワークを作り、メンバもそれを利用してコーディングしている。どこにでもあるような構図であるが、ドキュメントが一切存在しないため、ソースコードを読んで理解しなければならない。超多忙なプロジェクトであり、新規参入者であっても、新人でない限りいちいち詳しい説明などない。

自分ひとりでできるくらいの規模であれば、他人のコードを理解してそれを利用するより、自分で作った方が遥かに効率がよいと常日頃思っている。しかし、主要メンバが使っているそのフレームワーク（というかライブラリ）を使う/使わないとは別に知識として知っておいた方がコミュニケーションは取り易いだろうということと、５０歳を超えていると思われるそのベテランプログラマがどんなコードを書くのかに多少の興味があったので、そのコードを眺めてみた。

コードをそのまま日本語に訳したような意味のない目障りなコメントやキャメルケースとハイフンの統一性のないネーミングなどについては、これまで数多くのコードで目にしているため、そのレベルのものはあまり期待していない。変数にローマ字綴りを使うのも許そう。タブとスペースが混在したインデントなのも、まぁ仕方ない。しかし、変数や関数名などに堂々と英語のスペルミスをしているのを見ると良識を疑いたくなる。「コードの細部に神は宿る」と言われるように、コードに対して崇高な価値を置いている僕にとって、非常に気分を害された思いがした。５０歳を超えてプログラマでいるからには、僕のような人間と少なからず価値を共有しているのではないかという勝手な期待があっさりと裏切られたのである。僕とは全く別の人種であった。

たかがスペルミス、と最初は思っていた。receiveがrecieveなのはネイティブでもよくある間違いだ。しかし、ところどころrecievになっているのを見たときその感性に疑問を感じた。さらにコードを眺めていると、dipsという変数がある。何かの略かと思ったが、文脈から想像するとdepthに相当する意味として使われている。dipsにそのような意味があるのか、知らないのは僕の方かと思い調べてみたが、どうもそのような意味はない。さらに、ReDrawやReScale, ReSize, そしてRectAngleを見たときには気分が遠のいた。確かに語源はその通りであろう。しかし、BaseBallやDataBase、InterNetなどと書かないように、一つの単語として定着しているものをこのように書くことはない。さらに見ていると、極めつけにfreamというスペルがあった。ライブラリの公開関数の名前の一部に使われている。どうもframeの意味らしい。これはスペルミスというより、意図的にそうしているとしか思えない。

いくら仕事とはいえ、このようなスペルの関数を使ってコードを書きたくはない。自分のコードが汚される思いがする。既にプロジェクトは終盤に入っており、しかも広範囲に亘って使われているため、修正のリスクを考えると、新規参入者である僕がとやかく言うことではない。幸い僕が担当した部分は比較的独立したモジュールであるため、それらを使わなければならないという状況ではない。スペルなどそんな些細なことはどうであれ、結局ちゃんと動作して無事に製品として出荷できればよいという考えもあることは認めよう。しかし、「割れた窓ガラス」が示すように、このような些細なことをしっかり改善しない限り、コードの品質維持は期待できない。コードにはその人の価値観や生き方までもが反映されるということを肝に銘じておくべきである。