わかりにくいプログラム

最近の雑誌やWeb系のコンテンツで、ソフトウェア開発に関する記事はとかく、
- テスト駆動とかテストを書かないとダメとかカバレッジ
- 開発フロー(Git Flow とか？）とか GitHub
- はやりのフレームワークの解説
- プログラミング言語の新機能の解説

ばかりになって、そういう勉強するの大事なのわかるけど、いろいろもの知りな人でも、もっとその手前の、「プログラムを書くための経験」が、足りてないのかなぁ、わかりにくいなぁ、って思うことがある。

それは、ある程度は仕方のないことで、昔はなんでもかんでも自分で書かないとでき上がらなかったけど、今は良さげなフレームワークをいい具合に組み合わせることができることのが大事。時代が違うとも言える。

で、そのわかりにくいプログラムってどういうのか？って自分なりに考えてみる。
例えば、使ってる単語が（日本人が）いかにも辞書で調べたものになっちゃいました、とか似て非なる単語を同じ意味で使ってしまっていてわかりにくかったり、 prefix とか suffix の付け方に一貫性がない、とか。
あと、最近はあまりみないけど、80カラムに納めたいために、単語を使うときに省略したり省略しなかったり一貫してない識別子の名前付けのは昔よく見たな。

オブジェクト指向開発でいうとあまりにも小さくて「気の利いた便利メソッド」みたいなのをいっぱい作り過ぎて、どれ使っていいかわからない（どれを使ってももいい）とか。
これは、好みの問題なのかもしれないけど、僕はあまり分割せず、長めのメソッド、関数のほうが好きみたい。

わかりやすいコードって僕が感じるのは、できるだけ少ない単語の組み合わせで一貫した prefix suffix の付け方をしているんだと思う。
昔 OSF/Motif でプログラムを書いたけど、 X とか Motif のツールキットライブラリはそこらへんの一貫性が保たれていて、オブジェクト指向も C 言語で Motif プログラミングで、「あ、このポインタがオブジェクトなんだなぁ」と感じた。

こういうのを一般化して書籍化するの難しそうだし、自分がわかりにくいなぁ、と思ってるコードをほかの人がなんの苦もなく読んでるのを見ると、僕だけが馬鹿なのかなぁ、とも思う。

結局、わかりにくいプログラムというものが、わかりにくくてよくわからないし、自分がわかりやすいプログラムが書けてるかよくわからない