見やすいソース

　現場で、見やすいソースについて話をしていたときに、わりと新人の方が、「処理が一箇所にすべて書いてあったほうが、分かりやすい」と言ったことで、自分も昔そう思っていた時期があったなと思い出したので。

　自分はＪａｖａから本格的にプログラムを始めたので、周りはオブジェクト指向・オブジェクト指向と連呼していて、オブジェクト指向ではない、わかってないようなプログラムを書くのは素人扱いでした。
　他の人のプログラムは、どこで何をやっているのかわからず、理解するにも周りの人の力を借りることも多かったです。
　このときの見やすいソースといえば、自分の見えないところでよくわからない処理をしていないことが前提で、そう考えるとおのずと、一箇所ですべての処理を記述している方が分かりやすかったと思います。

　この一箇所ですべての処理を書いたソースを仮に、巻物としましょう。
　巻物と本はどちらが読みやすいでしょうか？

　これは、文量にも内容にもよると思いますが、文量が増えれば増えれるほど本だと思います。
　それは必要な箇所だけを目次で探して読むことが出来るからです。
　何を理解するにも、書籍の初めから最後まで読まなければ分からないとしたら、効率が悪すぎます。ビジネス文章でも、結論を初めに書く習慣があります。

　とはいえ、目次のタイトルと内容が違っていたり、章、節の区分けがきちんと出来ていなければ、全部を読んでみるしかなく、そうなれば巻物を読むのとあまり変わらないかもしれません。
　見やすい文章というのは、思いつくままに書いたものではなく、話しの流れや構成を考え、きちんとまとめたものです。
　章のタイトルや副題で、そこに書かれている内容のおよそが想像できる、話があっちこっちに飛んでおらず、一箇所でまとめられているなど。
　読み手が必要な箇所だけを読めば分かるようにと意識することで、コーディングにも、文章術に通じるところがあると思います。

　結局のところ、オブジェクト指向も構造化プログラミングも、見やすいプログラムを作るための分割手法と思っているのですがどうでしょう？

　また、コメントについても、思いつきで書くのではなく構成としての書き方があると思いますが、参考書などは文量削減の為か、ほとんどないものもあります。
　会社毎の規約による文化の違いもありますが、参考書は標準的なコメント文もきちんと書くべきだと思うのですがどうでしょう？＞この辺から読みやすさより処理内容重視なのかなと

　今では、一通りのソースは追えるようになりましたが、見やすいソースにお目に掛かることは少ないです。
　自分の書くソースも、人から見て読みやすいかどうか、何を持って見やすいというのか、常に気になるところです。