プログラムを組むにあたってやるべきことは、ＶＢＡに限らず、手順を明確にすることである。できれば、フローチャートを書いておきたい。正確で詳細なフローチャートは、そのままでプログラムのようなものだから、もはや完成したも同然。フローチャートの書き方を知らないとか、面倒だと言うなら、適当なメモ書きでも構わない。頭の中だけで構想して作業することは、プログラムを作ると言うどころか、バグを作ると言うべきだ。

エクセルＶＢＡでは、ワークシートとプログラムは密接に関係する。ワークシートに数式を入れておくことで、プログラムを組むよりも簡単に処理が出来るケースが多々ある。例えば、あるセルの内容と関係のあるデータを求めるのなら、プログラムでループや条件判断をさせるよりも、ワークシート上にテーブルを作っておいてLookUp関数を使った方が良い。ワークシートの数式とプログラムを上手く組合せてやることが肝心である。

手順書が出来たら、プログラム中で使用する変数についてもリストを作ると良いだろう。手順書と変数リストが揃っていればメンテナンスも楽。汚い字で人に見せられないなら、出来あがったプログラムにコメントを書き込んでおくと良い。プログラムがある限り、コメントもあるわけだから、ウッカリ失くすことも無い。

プログラムの全体像を書いたら、これをいくつかのブロックに分けよう。できればサブルーチンやファンクションとする。そうできなくても、「これの次はこの処理」てのを明確にしておき、順番にプログラムしていくようにする。例えば、エクセルＶＢＡでは、画面表示と自動再計算を停止すると処理が圧倒的に速くなる。だったらサブルーチンにしておいて、メインのプログラムからの呼び出し１発で済ませてしまえば良いだろう。

こうしていよいよプログラミング（正確に言うとコーディング）に入るのだけど、ここでもう一つ、エラーとかイレギュラーデータへの対処を考えておこう。ワークシート上の数式がエラーになった場合も忘れずに。完璧なプログラムでエラーが起きないとしても、元のデータが予期せぬ物になることはある。オペレーション時のミスもありえるし、理由が良くわからないままにプログラムが停止するよりは、警告メッセージを出してやった方がずっと良い。ちなみに、デバッグする前にエラー処理を入れておくとデバッグの意味が無くなったりするので、これも注意しておいて欲しい。

気の効いたプログラムってのはいくつかの点で評価されると思うが、例えばこんなこともあるんだ、と思うことを並べてみよう。

• 複雑ではなく、流れが見易く記述されていること。
• 全体として記述や処理テクニックが一貫していること。
  多種多彩な「技」が駆使されているのは必ずしも良いとは言えない。
• 動作の進捗が確認できること。
  動いているのか止まっているのかも解らないものは大変困る。
• 長い処理ならば必要な入力を最初に全て行わせるなど、操作が楽であること。
• 処理終了時に結果を表示すること。
  単なる「終了しました」メッセージだけでも良い。
• 処理の中間結果を適切に残すこと。

プログラムの見易さや汎用性やメンテナンス性を重視して行くと、処理速度（時間）を犠牲にしなければならないケースがある。双方のバランスを取ることは結構難しい問題ではあるが、速度の改善は後でも出来ると考え、多少の犠牲は止むを得ないと考えるべきであろう。そもそも、「待っていられない」ほど時間がかかる処理なのだとしたら、それをＶＢＡでやること自体か、もしくは、プログラムの基本的な構造に問題があるのではないかと思う。（最近のＰＣは高速だしね）

ここでは、狭義で「プログラム」という言葉を用いている。本来は仕様を作ること自体は立派なプログラミングである。