4

私の最初の言語として、そして他の人の例から完全に教えられたように、この例のように、スコープが適用されるモジュール、ルーチン、または関数の開始時にすべての変数宣言をグループ化するという VBA の標準的な慣行に疑問を呈したことはありません。

Sub Traditional()
Dim bVariable as Boolean
Dim OtherVariable
' Some code using OtherVariable goes here
'
' Now we use bVariable
bVariable = True
Do While bVariable
    bVariable = SomeFunction()
Loop
End Sub

現在、他の言語での標準的な慣行は、次のように、変数が使用される場所のできるだけ近くで変数を宣言することであることを学んでいます。

Sub Defensive()
Dim OtherVariable as String
' Some code using OtherVariable goes here
'
' Now we use bVariable
Dim bVariable as Boolean
bVariable = True
Do While bVariable
    bVariable = SomeFunction()
Loop
End Sub

これは防御的なプログラミングの実践として私には完全に理にかなっているように思えます-スパンとライブタイムの両方を制限するという点で（Code Completeで説明されているように）、VBAで同じことをしない理由があるかどうか疑問に思っていますか? 私が考えることができる考えられる理由は、メモリ、実行時間 (たとえば、ループ内で繰り返し宣言する)、伝統です。ルーチンの開始時にすべての変数が使用されることを期待している VBA プログラマが何十万人もいるに違いないため、これはおそらく正当な理由です。このプラクティスの利点、または少なくともそれがどこから来たのかを説明するかもしれない、私が見逃したものはありますか?

4

2 に答える 2

2

すべての変数を先頭で宣言します。それらを最初の使用マスクに近づけることを宣言すると（少なくとも）最初に修正する必要がある他の2つの問題があると思います。

  1. 手順が長すぎる: 手順が画面に収まらない場合は、処理が多すぎるため、小さなチャンクに分割する必要があります。また、プロシージャーが小さく、1 つのことしか実行しない場合は、単体テストの方がはるかに簡単に記述できることがわかります。
  2. 変数が多すぎる: 関連する変数が多数ある場合は、カスタム クラス モジュールまたはユーザー定義型の使用を検討してください。これにより、コードが読みやすくなり、保守が容易になります。

プロシージャーが短く、クラスと UDT を使用している場合、使用時に変数を宣言する利点は少なくなるか、なくなります。

于 2012-12-13T18:30:29.450 に答える
2

どちらの方法も、VBA でのコーディング スタイルが異なるだけだと思います

古い C 標準では、すべての宣言を先頭に置く必要がありました。この習慣を取り入れて、VBA などの他の PL に持ち込む人も多いと思います。

一番上で変数を宣言すると、変数名の短いリストが明確になります。変数名の長いリストは読めません

使用されている場所の近くで変数を宣言することは、後で紹介されます。このプラクティスには、オプティマイザーまたは VBA よりも広いスコープを持つ PL の「最上位で宣言する」よりも明らかな利点があると思います。(スコープが FOR ループでのみ表示される変数を宣言できるように) その後、オプティマイザーがスコープを変更します。(VBAで言えば、GLOBAL変数をPROCEDURE変数に変更する場合があります)

VBA の場合、パーフェクトなし

于 2012-12-13T10:22:40.797 に答える