Javadocもまあそれなりに書いていますし、
きわどいところにはそれなりにコメントも入れています。
全てのメソッドは長くても50行かそこらですし、
クラスだって長くて300行かそこらです。
というか、
長いクラスはみんなJavaBeansです。
サイクロマチック数だって一桁をキープしています。
うんうん、
これなら読みやすいに違いありません。
あ、次の担当者の方を見つけました。
ちょっと読んでもらいましょう。
あれ？
何か顔が青ざめているような…
はいストップ！
今回の話題はこれです。
ずばり“読みやすいソースコード”とは何かについてです。
でもこれが読みやすいソースコードだとか主張する気はありません。
十人十色とはよく言ったもので、
読みやすいソースコードも十人十色だと言いたいからです。
ポイントと思われるのは、
よく言われる「凝ったテクニックの実装は読みにくい」という部分です。
確かにその通りという部分は大きいです。
IOCCC大好きな自分にとっては身近なことです。
でも*凝った*といわれるテクニックってどこからなんでしょう？
とりあえず具体例を、
どっちが読みやすいですか？
パターンA
hoge(1); hoge(2); hoge(5); hoge(11); hoge(14); hoge(20); hoge(21); hoge(77); hoge(100);
パターンB
int[] parameters = {1, 2, 5, 11, 14, 20, 21, 77, 100};
for (int parameter : parameters) {
hoge(parameter);
}
全員がBを選ぶと信じたいところですが、
Aの方が良いという方がそれなりにいるようなのです。
だいたいこういう方は、
新たに関数を作るだけでアレルギー反応が出ます。
そりゃ4桁や5桁の行数にもなる関数を平気で作るわけです。
彼らにとってはその方が*読みやすい*んですから。
この例はかなりアンダーを攻めたものですけど、
色んな所で読みやすさのラインが登場します。
有名どころは以下でしょうか。
・構造化定理
・オブジェクト指向
・命名規則
・正規表現
・再帰関数
・関数型言語(っぽいこと)
※別に難易度順とかじゃありません。どっちかというとカテゴリー？
全てのプログラマーは、
この何次元にも展開された無数に渡るラインのどこかに立っています。
そして自分のいるラインに近い場所が読みやすいソースコードなわけです。
遠ければ遠いほど読み
あまりに位置が遠いプログラマー同士が、
一緒に仕事をしたときに不幸が起こるのではないでしょうか。
あなたがもしも、
「読みやすいソースコードを書こう。」言ったことがあるのであれば、
それはどこの人達にとってですか？
