Excel VBAの可読性を高めるために（具体例編）
- yuji fukami
- 1月26日
- 読了時間: 14分
更新日：1月28日
はじめに
この記事では、Excel VBAの可読性を高める具体例について解説します。前回の概要編で触れた基本原則に基づき、具体的な良い例と悪い例を比較しながら、実践的な改善方法を学びます。さらに、プログラムの保守性や再利用性を高めるための具体的なテクニックも紹介します。
前回記事
まずは、可読性を高めるためのルールを一覧形式で紹介し、その後、具体例について解説します。
可読性を高めるルール一覧
次章からは、これらのルールに基づく具体例を見ていきます。
可読性を高めるルールと具体例
1. インデントを適切にする
悪い例:
良い例:
ポイント: インデントを適切に使うことで、コードの構造が明確になります。
初心者が書いたコードは、上級者から見ると意外とインデントが整っていない場合が多いです。まずは初心者を脱却するためにも、インデントをしっかりと整える習慣をつけましょう。これにより、コードの読みやすさが飛躍的に向上します。
2. 変数名は意味が分かるものにする
悪い例:
このコードでは変数名が抽象的すぎて、コードを読んだ人がすぐにその意味を理解することが難しくなります。
良い例:
意味のある変数名を使うことで、変数の役割が明確になります。
さらに良い例:
日本語の変数名を使うことで、特に日本語を母国語とする開発者には意図がさらに伝わりやすくなります。
さらにさらに良い例:
型を明示する接頭辞（Lng_やDbl_）をつけることで、変数の型が一目で分かりやすくなります。
さらに、VBAのインテリセンス（Ctrl + Space）の候補において変数名が途中まで入力した段階で正確に表示され、コーディング効率が向上します。
日本語変数のみを使用した場合、日本語入力モードへの切り替えが必要になり、インテリセンスの利便性が低下する可能性がありますが、型接頭辞を加えることでそのデメリットを回避できます。
ポイント: 意味のある変数名を使用することで、コードの意図がすぐに理解できます。
3. 必要最低限のコメントを追加する
悪い例:
このコードでは、何を達成しようとしているのかが明確ではなく、コードの目的を理解するのに時間がかかります。
良い例:
必要最低限のコメントを追加することで、コードの目的が明確になり、後から見たときの理解が容易になります。
コメントの記述ポイント:
くどくなりすぎない: 明らかに理解できるコードに対してはコメントを省略します。
変更の理由を記述: コードの処理内容だけでなく、なぜその処理を行ったのか、背景や意図もコメントとして残すと有効です。
ポイント: コメントを加えることで、コードの目的が明確になります。
4. ネストは深くしすぎない
悪い例:
良い例:
ネストを分割することで、コードの読みやすさが向上します。
ネストが深いコードは、人間がどの部分がどの範囲までループしているかを記憶しながら読む必要があり、負担が増加します。特に、深いネスト構造は複雑なアルゴリズムで発生しやすく、コード全体が読みにくくなる要因となります。
そのため、サンプルコードのように処理を分岐して別のプロシージャに記述する方法は非常に有効です。また、最大ネスト数を制限する意識を持つことが、可読性の高いコードを維持するポイントとなります。
5. 変数型はしっかり明示
悪い例:
ポイント: このコードでは、変数の型が明示されていないため、以下のような問題が生じます:
変数の型が不明瞭で、コードの意図を理解しにくい。
型の不一致により、意図しないエラーや動作が発生する可能性がある。
良い例:
ポイント
変数の型を明示することで、コードの意図が明確になります。
型エラーを未然に防ぐことで、予期しない問題を回避できます。
実務で使用する変数名を使うことで、より現実的なシナリオに即したコード例となります。
さらに良い例:
ポイント
「2. 変数名は意味が分かるものにする」でも説明した通り、変数名に変数の型の省略文字を入力しておくと、さらに可読性のみならずコーディングがしやすくなります。
6.入力、処理、出力を意識
悪い例:
ポイント:
このコードでは、セル間で直接値を操作しているため、各セルが何を意味するのか不明瞭であり、コードの意図が理解しづらい。
良い例:
配列を使用して入力、処理、出力を明確に分けることで、コードの意図が伝わりやすくなり、後からの修正や保守が容易になります。
配列を使うことで、セル操作の回数を減らし、パフォーマンスの向上が期待できます。
7.一つのプロシージャの行数を長くしすぎない
1つのプロシージャ内に多くの処理を詰め込むと、以下のようなデメリットがあります：
理解しづらい: プロシージャが長くなると、途中でどの処理が何をしているかを人間が記憶しながら読み進める必要があります。これにより、コード全体の意図を理解するのが難しくなり、ミスを引き起こす可能性が高まります。
保守性が困難になる: 長すぎるプロシージャでは、特定の処理部分を修正する際に、他の部分への影響を確認する手間が増えます。その結果、修正に時間がかかり、バグが発生するリスクも高まります。
再利用性が低下する: プロシージャが長いと、その一部だけを他の場面で再利用することが難しくなります。再利用性が低下することで、コードの効率が悪くなり、同じ処理を何度も記述することになりがちです。
推奨行数:
1つのプロシージャの長さは、50行以下を目安とし、長くても100行以内に抑えることが推奨されます。この行数は、VBAエディタの画面でコード全体が一目で確認できる範囲に収めることを意識したものです。これにより、コードの全体像を把握しやすくなります。
対策:
どうしても処理が長くなる場合は、以下の方法で分割を行います：
別のプロシージャとして分岐: 処理を小分けにし、役割ごとに独立したプロシージャに分けます。
引数を活用: 必要なデータを引数で渡し、処理結果を戻り値として返す関数を利用します。
これらの方法を使うことで、コードの可読性と保守性を大幅に向上させることが可能です。
8.ステートメント(IF、For、Doなど)の行数は長くしすぎない
「一つのプロシージャの行数を長くしすぎない」で解説した内容とほぼ同様の理由で、ステートメントの行数も適切に制限することが重要です。
1つのステートメント（If文やFor文）が長すぎると、以下のようなデメリットがあります：
理解しづらい: If文やFor文が長くなると、その中での処理内容を記憶しながら「この処理はIf文の中だ」と認識し続ける必要があります。これにより、人間の記憶負担が増加し、処理の流れを把握するのが困難になります。
保守性が低下: 長いステートメントでは、特定の条件分岐やループ内の処理を修正する際に、影響範囲を確認する手間が増え、修正ミスや意図しないバグを招く可能性があります。
9.変数の宣言は使用する場所に近く
変数の宣言を使用する場所の近くに記述することで、以下のようなメリットがあります：
コードを追いやすい: 変数の宣言と使用箇所が近いと、宣言部分を確認した後すぐにその変数がどのように使われているかを追いやすくなります。例えば、VBAではShift + F2で変数の宣言場所にジャンプできますが、宣言と使用箇所が遠いと何度もスクロールや検索が必要になり、手間が増えます。
可読性の向上: 変数が宣言された直後に値を代入するコードは、その変数の役割や初期値が一目で分かるため、コード全体の意図を理解しやすくなります。特に、変数の初期値や型が重要な場面では、近くに記述することで混乱を防げます。
エラーの防止: 変数を宣言してから使用箇所までが離れていると、途中で変数の目的を見失いやすく、誤った使い方をするリスクが高まります。
推奨:
変数の宣言は、使用箇所の直前または近くに記述しましょう。
変数の宣言と初期化を同時に行う場合、コロン（:）でつなげるとコンパクトに記述できます。
悪い例:
良い例:
ポイント:
変数の宣言と使用箇所が近いと、追いやすくなる。
セミコロンを使って1行にまとめることで、可読性を損なわずにコードをコンパクトにできる。
ただし、セミコロンを使いすぎると逆に読みにくくなるため、適切なバランスを心がけましょう。
10.グローバル変数は乱用しない
グローバル変数とは、モジュールの外側またはトップレベルで宣言されるPrivateやPublicの変数を指します。これを乱用すると、以下のようなデメリットがあります：
値の追跡が困難: 複数のプロシージャやモジュールでグローバル変数を使用すると、どこでその値が変更されたのかを追うのが非常に難しくなります。その結果、バグの原因が特定しづらくなり、デバッグに時間がかかることがあります。
保守性の低下: グローバル変数が頻繁に変更されるコードでは、修正時に予期せぬ影響が他の箇所で発生するリスクが高まります。また、他の開発者がコードを読む際に、グローバル変数がどのように使われているかを理解するのに時間がかかります。
コードの見通しが悪くなる: グローバル変数が多すぎると、コード全体の構造が不明瞭になり、どの変数がどの処理に影響しているのか把握しにくくなります。
推奨:
グローバル変数を使わず、以下の方法で代替する：
引数を利用: 必要なデータはプロシージャ間で引数として渡す。たとえ手間がかかっても、引数を明確に指定することで、コードの流れが追いやすくなります。これにより、保守性や可読性が向上します。
戻り値を活用: 結果を関数の戻り値として返すことで、処理結果を明確に管理できます。
グローバル変数は、一見便利に思えるものの、乱用することでコード全体の保守性が大きく低下します。面倒でも、明示的に引数や戻り値を使用する方が、結果としてコードの可読性が向上し、デバッグや修正がしやすくなります。
これらの工夫を行うことで、コードの可読性や保守性が向上し、予期せぬエラーを防ぐことができます。
11.省略はしない
Excel VBAでは、省略可能な記述が多くありますが、省略することでコードが読みづらくなることがあります。特に、省略されたコードは後から読む際に、「どの部分が省略されているのか」を頭の中で意識しながら確認する必要があり、その手間が発生します。そのため、コードを省略して書く手軽さよりも、後で読む際の手間を考慮して、読みやすい記述を心がけることが重要です。以下に、主な例とその影響を挙げます：
Rangeオブジェクトのデフォルトプロパティ（Value）の省略:
Valueを省略すると、セルの値なのか、セルオブジェクトそのものなのかが曖昧になります。これにより、意図しない動作やバグの原因となる可能性があります。ただし、具体的なエラー例の解説は今回割愛しますが、このような問題を回避するためにも、極力Valueを省略しない記述を心がけましょう。これにより、事前に予期せぬエラーを避けることができます。
Callステートメントの省略:
Callステートメントを記述することで、この行が別のプロシージャを実行していることが一目でわかるようになります。
変数の型宣言の省略:
型を省略するとVariant型になりますが、これは意図しない型のデータを扱う原因となり、コードの保守性が低下します。
ポイント:
コードを読む人が「ここは省略されている」と意識せずに済むよう、明示的な記述を心がけましょう。
面倒に思えても、省略せず記述することで、コードの可読性や信頼性が大幅に向上します。
12.セル値、配列の要素の単体の値は一度(意味の分かる名前の)変数に格納して処理する
セルの値や配列の要素を直接処理すると、コードが読みづらくなり、意図しないバグを引き起こす原因となります。たとえば、セルの値を直接計算に使用した場合、そのセルが何を意味しているのかが不明確で、後からコードを読む際に混乱を招きます。また、セルや配列のデータ型が不明確な場合、意図しない型変換が行われる可能性もあります。
この問題を防ぐために、セルや配列の値をまず意味の分かる変数に格納し、その変数を使用して計算や処理を行うことが推奨されます。これにより、可読性が向上し、デバッグや保守が容易になります。
悪い例:
良い例:
ポイント:
変数名を意味の分かるものにする: 変数名を「単価」や「数量」とすることで、コードを読むだけで値の意味が伝わります。
変数の型を明示する: 型を指定することで、意図しない型変換やエラーを防ぐことができます。
途中の計算処理を変数に格納する: 処理の流れが明確になり、コード全体の可読性が向上します。
この方法を適用することで、コードの信頼性と可読性を高めるだけでなく、後から処理内容を変更する際の柔軟性も向上します。
13.Go Toであっちこっち飛びまくるのはダメ
Go To 文は、VBAにおいて特定のラベルに処理を飛ばすために使用されます。しかし、これを乱用すると、以下のような問題が発生します:
処理の追跡が困難になる: Go To を多用すると、処理がどこに飛ぶのかがわかりにくくなり、コード全体の流れを理解するのが非常に難しくなります。
順序通りに処理が進まなくなる: 上から下へ順番に処理が進むコードが通常は読みやすいですが、Go To を使用すると、処理が飛び回るため、読んでいる人にとって混乱を招きます。
デバッグが難しくなる: エラーが発生した場合、処理が飛び回るため、どの部分でエラーが発生しているかを特定するのが困難になります。
推奨事項
Go To を使用しない: エラー処理など特別な場合を除き、基本的に Go To の使用を避けましょう。
代替手段を活用する: 条件分岐やループ制御 (If...Then, Select Case, Exit For, Exit Sub など) を用いることで、コードの可読性と保守性を向上させることができます。
14.「こう書いた方が読みやすい」というのを常に意識する
結局のところ、可読性の高いコードを書くためには、単にルールを守るだけではなく、常に「どう書けば後から見た人にとって読みやすいか」を意識することが重要です。この記事で紹介したルールは、可読性を向上させるための基本的な指針ではありますが、最終的には日々の実践を通じて自分の中で洗練させていく必要があります。
主なポイント
習慣化する可読性を意識したコードを書けるようになるには、時間がかかります。一日で習得することは難しいですが、毎回コードを書くたびに「こう書いた方が後から見たときにわかりやすいかもしれない」と考える習慣をつけましょう。
フィードバックを活用する
自分の過去に書いたコードを見直すことで、「ここはもっとこう書けば読みやすくなったな」という改善点が見つかります。
他の人が書いたコードを読むことで、新しいアイデアや改善方法を学ぶことができます。良い部分は取り入れ、悪い部分は反面教師として活かしましょう。
試行錯誤を繰り返す初めから完璧なコードを書くのは難しいため、いろいろな書き方を試しながら、自分にとっても他の人にとっても読みやすいスタイルを追求することが大切です。
「正攻法」としてのアプローチ
特に初心者から中級者の間では、「とりあえず動くコード」を目指しがちです。しかし、実際に現場で使われるコードや、他の人がメンテナンスを行うコードでは、「動けば良い」だけでは不十分です。以下のアプローチを意識しましょう:
他人が読むことを前提とする自分が読めるだけのコードではなく、他人が見たときにその意図や処理内容がすぐにわかることを目指しましょう。
柔軟性を持つ
一つのやり方に固執せず、異なるアプローチを試してみることで、自分のスタイルをより洗練させることができます。
必要に応じて、ルールを応用的に使い分ける力も重要です。
意識的な改善を続ける日々意識的に改善を続けることで、少しずつコードの質が向上します。これが最短のようで最も確実な道と言えます。
最後に
「可読性の高いコードを書く」というスキルは、経験を積み重ねる中で少しずつ身につくものです。この記事で示したルールや例は近道を提供するものですが、最終的には「こう書いた方が読みやすい」という意識を常に持ち続けることが何より大切です。自分のコードを見直し、改善を繰り返しながら、可読性の高いコードを書く力を育てていきましょう。
コメント