今回はバグが発生しないためにどんなことを気をつけたらいいのか、
実際にプログラムを書く際のポイントを少し上げてみたいと思います。

１：コメントは実コードよりも先に書く

コメントは必ず実コードよりも先に書きましょう。
自分がやりたい挙動、まだ達成していない夢を書きましょう。
コメントを後から読むのは他人です。
未来の自分を含めた他人が読んだ時に、「これを書いた人はこうしたかったんだな」という思考の痕跡を残すこと、これがコメントの意義だと思ってください。
またコメントの内容は「理解してもらえること」を前提に書いてはいけません。
読む相手の理解力・読解力に依存せず、「誤解・曲解させないこと」を目指して書きましょう。

２：意味の流れが同じものはまとめて書く

プログラムを読み解く場合、１行毎に別の対象に対して処理しているよりも、
同じ対象に対して処理している行が固まっているほうが理解しやすいものです。
「この辺のブロックは大体◯◯に対しての処理なんだな」という大まかな理解の指針が与えられるからです。

ところが思いつくがまま１行毎に意味合いがバラバラな処理を書いていると、
全体としてまとまりがないプログラムになってしまい、頭で整理する際にも余計な負荷がかかってしまいます。
このようなプログラムだと各塊に意味がないため、処理の因果関係におかしな行があってもとても気づきにくいです。

純文学が並んでいる本棚に１冊だけ花とゆめコミックスが並んでいるケースと、
様々な本が並んでいる本棚に１冊だけ花とゆめコミックスが並んでいるケース、
どちらが違和感に気づきやすいでしょうか？

３：記述ルールを遵守する

コーディングルールについては意見が色々分かれるので細かい話をするつもりはないのですが、１つだけ大事なのは自分の記述ルールはどんな時でも貫くということです。
if文のたびにヨーダ記法と逆ヨーダ記法が交じり合う・・・ような不徹底はしてはいけません。
バグ発生に対して一番最初にできることは自分に対して警告を発することです。
大体のコーディングルールは遵守すれば可読性はそれなりに上がります。
可読性が上がるということは読み返しやすいということ、読み返しやすいということはプログラムのチェックもスムーズに行えるということです。
難解な、難読なプログラムを書けばそれだけバグが潜む隙間が産まれます。
できるかぎり可読性を高め、難しい内容でも極力シンプルに読みやすく書く事で確認しやすくしましょう。

４：デバッグ用のコードには検知しやすいルールをつける

プログラムを書くうえでデバッグしない人はいないと思います。
そしてデバッグは当たり前ですが、いずれプログラム上から消されるものです。
ですがデバッグコードを入れ過ぎると、どこに埋め込んだのか把握しづらくなり、
リリース時にそれが残ってしまうケースがあります。
単なるイージーミスなのですが、気をつければ回避できる程度なので非常にもったいないミスとも言えます。
デバッグコードには一定のルールを入れて、リリース前にきづけるよう目印にしましょう。
僕だと
//XXX
print __FILE__. “::”. __LINE__. “
¥n”;
という目印を埋めてデバッグの取り忘れが減るようにしています。

往々にしてバグはつまらない事が原因だったりします。
自分を過信せず、どんなイージーミスでも起こりうるものと考え、
ほんの少しでも発生率を下げるよう努力する姿勢が大事なのではないかと思います。

【関連記事】
エンジニア解体新書
エンジニア解体新書　2之巻
エンジニア解体新書　3之巻
エンジニア解体新書　4之巻
エンジニア解体新書　5之巻
エンジニア解体新書　6之巻
エンジニア解体新書　7之巻
エンジニア解体新書 8之巻
エンジニア解体新書 9之巻
エンジニア解体新書 10之巻
エンジニア解体新書 11之巻
エンジニア解体新書 12之巻