プログラムは保守性と可読性を重視しよう

全部ではないにせよ、原則的に保守性と可読性を重視したコーディングがよいのですが、何が保守性が高く、何が可読性が高いのかがわからないといけないですね。

【オブジェクト指向でやりがちな設計】

オブジェクト指向のプログラム言語は、とかくクラスまみれになりがちです。
オブジェクト指向なのでもちろん、クラスやスーパークラス、インターフェイス、継承は当然利用してよいものですが、やりすぎは保守性と可読性の両方を落とします。
張り切ってクラス継承しまくると、目的のプログラムコードにたどり着くのに、3つくらいクラスを潜らないといけない・・・時間の無駄です。
もし、それが必要にせまられてのなら、設計自体に問題があるのでは?
わたしは最大2つくらいに抑えます。

【ビジネスロジックと汎用的な処理をきっち区別する】

Webアプリケーションや、業務用アプリではビジネスロジック部分と汎用的処理の部分が出てきます。それらをきっちり住み分けしましょう。そうすることで、保守性が高まります。

例えば、Webアプリケーションの簡単なお問合せフォーム1つでもそうです。
入力するのは、「名前、電話番号、メールアドレス、メッセージ」たったこの4つの入力フォームでも、このことは言えます。
ここでビジネスロジックは、この4つのフォームの値を受け取るロジック箇所とヴァリデーションチェックのエラー処理です。それ以外の、ヴァリデーションチェック、メール送信、画面表示は汎用的処理として、住み分けします。そうなると、必然的にこの汎用処理箇所はクラス化になり、他のアプリケーションでも流用可能となりますので、別ファイルでなるでしょう。
バグが発生しても、クラス自体を予めきっちりデバッグしておけば、最初にバグ発生個所として疑うべきはビジネスロジック部分になります。

【オリジナルでも命名則やコーディング規約を持っておく】

可読性を高める基本です。極端に言えば、どんな命名則でもコーディング規約でもよいと思います。

例えば、
$obj_xxx は、オブジェクト変数だが、ローカルスコープ。
$OBJ_xxxは、オブジェクト変数で、グローバルスコープ。
$cfg_xxxは、自作のコンフィグファイルを読み込んだ内容。 などなど。
これだけで、可読性が一気にアップしますね。

【Webアプリケーションは、インラインで書かない】

これは基本ですね。
JSP,PHP,Perl,ASP・・・HTMLタグの中にインラインで埋め込むなど狂気の沙汰です 笑。
HTMLの出力箇所と、ビジネスロジックは物理的に別ファイルにします。
HTMLをテンプレ化で利用すればよいですね。

【Webアプリケーションで、ヘッダーとかフッターとか・・・】

結構いますね、こういう書き方する人、ダメです。
例で言うと、ワードプレスなんかはそういうのが多く、最悪です。
保守性と可読性が激減します。
ヘッダー箇所とフッター箇所をPHPなどで分割で処理すると、一見「ヘッダーが変わっても、ヘッダーを処理するPHPを変えれば済むだけじゃん」と、考えます。
ところが、どんなヘッダーが表示されるか、つまりデバッグするには、Webで表示するしかないのです。他の箇所にエラーがあった場合は、犯人特定に無駄な時間がかかりますのと、Webデザイナーが直せないので、プログラマーがなさなければならないか、2人がかりになるため無駄な時間です。

【処理が早そうなコードよりも可読性が高い方が処理が早いぽい】

全部ではないとは思いますが、私がいろいろ試したところ、一見処理が早そうな形でFor文やIf文や連想配列を作るよりも、可読性が高くどこでどんなことをしているか、を中心にしたコーディングの方がバグが少なく、処理が早い気がします。

という具合でした。