ソースコードを読みやすくし保守性を高めるために、「GOTOは使わない方が良い」「クラスは小さく分けた方が良い」といったポリシーを良く聞きます。
しかし、これらのポリシーによりソースコードが読みやすくなるとは限りません。
例えば、「GOTOは使わない方が良い」というポリシーについては、制御構造を実現するためのフラグが増えてかえってソースコードが読みにくくなることがあります。「関数・パラグラフの最初と最後へのGOTOだけ許可する」という形で若干緩いポリシーにした方が個人的には好きです。
また、「クラスは小さく分けた方が良い」というポリシーについてもやりすぎは禁物で、あまりにクラスを細かく分けすぎるとソースコードの管理が大変になったり全体の構造を把握しにくくなったりします。
ソースコードを読みやすくする上で最も重要なのは、上記のような細かい話ではなく、ソースコードに一貫したポリシーがあるか、だと個人的には思っています。
ソースコードに一貫したポリシーがあれば、たとえ癖の強い（一般的なポリシーに則っていない）ソースコードであったとしてもそれなりに読みやすかったりします。
一貫したポリシーがあるソースコードには「予測可能性」のようなものがあると感じます。ソースコードを読んでいて「ああ、ビジネスロジックはきっとここにあるな」「インプット・アウトプットの定義はきっとここでしていな」といった具合で予測を立てながらスムーズにソースコードを理解することができます。
（これができていないソースコードは、たとえ自分が作ったソースコードであっても追うのに苦労します…）
例として、文章の書き方について考えるとわかりやすいと思います。
ある機関が発行している論文について、どの論文も「１．序論」「２．本論」「３．結論」となっていれば、「結論をかいつまんで把握したい場合は先に３（一番後ろのパラグラフ）を読む」といった形で予測を立てながら読むことができます。
しかし、論文によってポリシーがバラバラで、「１．序論」「２．本論」「３．余談」「４．結論」「５．後日談」のようになっている論文が混ざっていたら読みにくくてしょうがありません。結論が欲しい場合に、３を見ても一番後ろのパラグラフを見ても結論が書いてなく、わざわざ全体的に目を通す必要が出てきてしまいます。
一貫したポリシーを保つ上で、ネックになるのは複数人で開発する場合です。
複数人で開発する場合は、開発者毎でポリシーが異なるので、コーディング規約のような形でポリシーを定める必要があります。
コーディング規約がない、若しくは不十分な場合は、一般的に広まっているポリシー（例えば前述のgotoless文）に従ったり、既存のソースコードの書き方を真似ることが望ましいです。
オブジェクト指向のプログラム言語を使用しているのであれば、カプセル化や継承といった機能を使うことでポリシーに従っていないソースコードにコンパイルエラーを起こさせることもできるので、一貫したポリシーに基づいたプログラミングが容易になります。
