このブログへ到達するまでの検索ワードを確認すると、コーディング規約に関するものが多いようなので、そちらもたまには書こうと思う。
当たり前過ぎるような気もするが、意外と実践されていないのが、項目名、つまり変数名、定数名などの決め方だ。ただし、「世の中のあらゆるソースコードに対してこれがよい」というものではない。中には全く逆のことをした方がよい場合もある。しかし、VBAで通常のプログラミング／コーディングをするのならこのルールでよいかな、と思う。
なお、私はハンガリアン記法、つまり変数名の前に型を表す短縮文字を付けるよう推奨している。今の世の中の流れでは付けないようになってきている。が、自前で作ったクラスや利用頻度の少ない型はそれでもいいかもしれないが、Excel VBA で準備されている型のうち、頻繁に使うプリミティブな型、すなわちStringやIntegerなどには付けた方がよいと考えている。後述もそれを前提としている。
さて、本題に戻る。
例えば、昔のBASIC等では For ループを回すインデックスは i とか j、i1、i2、など付けて、更に汎用的に使い回す場合も多かった。しかし、例えばセルの列を順次見ていくためのインデックスなら iCol、行なら lRow など、コードを読んでいても分かる名称にした方がいい。バグ発生時や保守時の可読性が向上する。なお、列は Integer の範囲で収まるのでプリフィクス（先頭）に i 、行は Long でないと扱いきれないので l を付加している。
また、よくあるのが項目の略し方や表記だ。
商品コードという項目名をどう命名するか？SyohinCode、ShohinCD、ITEM_CD などなど。更にこのプリフィクスに String 型を表す s または str などを付ける。 このあたり、自分たちでどういう命名方法とするのか、方針を決めた方がよい。例えば、データベースに項目名があるのならその項目名を利用するのも手である。更に、方針を決めるだけではなく「この用語はこういう変数名にする」という辞書を作っておくとなお良い。実際、大規模なプロジェクトでは用語に関して項目名、型、サイズを決めることで、そういう所でのバグを防ぐとともに、ツールを用意して変数名をチェックさせていたりもした。こうしておくとVBEで検索を掛ければどこで使われているかが確認しやすいのである。
更に、Constは一発でそれである、と分かった方がよい。変数と表記を変える、プリフィクスに Const の C を付ける、などもいいだろう。
私の場合、ブック内で共有する Const なら Const 値をクラスモジュールに集めて利用している。それによりプリフィクスを付けて呼び出さざるを得ないので「Const値である」と認識できる。特定のモジュール内だけで使う Const 値、例えばデータベースアクセスのタイムアウトを持っておく場合などは、そのモジュール内の Private として定義し、Const値と分かる表記にしている。なお、私はクラスモジュール主体で、標準モジュールは必要な場合にのみ利用しているが、クラスモジュール内での Const値は Ptivate でしか定義できないため、誤って他のモジュールで利用してしまう、ということはない。
最後に、共通変数である。
プロジェクト全体の共通、モジュール内の共通と、各プロシージャ／ファンクション内の変数とをどう表記を分けるか。全体ならプリフィクスに g 、モジュール内なら m を付けたり、という手がある。まずはそれで区別してみてはどうだろう。
私の場合は、共通変数もクラス化してしまっている。いわゆるデータクラス、というもので、データクラスを処理間で受け渡している。どこでどう変化しているのか分からないようなものはなるだけ排除し、使い終わったら破棄すれば、他からの悪影響を受けにくい。この手法が使えないときにのみ前段の方法を採っている。
なお、データクラスについてはまだ試したいことがあるので、現段階ではあまり触れないでおく。いずれ、クラスを使ったものに関してはサンプルを提供していく所存である。
まとめると
・曖昧な名称で汎用的に使う項目を減らす、なくす。
・項目名の付け方はルール化し、可能なら辞書を作っていく。
・Const値は、それと分かるようにする。
・共通変数も、そのスコープが分かるようにする。
変数名がいい加減で、読みにくいメタボなコード とオサラバしたいおなら、このあたりを実践してみては如何だろう？ソースコードの整理、リファクタリングはそれからでも遅くない。