コードを書く場所で一般的なのは、ボタン内or一般モジュール内のSubそ

質問

コードを書く場所で一般的なのは、ボタン内or一般モジュール内のSubそれともFunction？

コマンドボタンを押してコードが実行されるとします。

Ｑ１．コードを書く場所
　? コマンドボタン内にコードを書く
　? 標準モジュール内にSubプロシージャで書いて、ボタンはそれを呼ぶだけ。
　? 標準モジュール内にFunctionプロシージャで書いて、ボタンはそれを呼ぶだけ。

　補足
　　　　同じなのかも知れませんが、皆さんは何処に書いてますか？
　　　　Functionにすると早いが、メモリに残ると予想しますが、どうでしょう？
　　　　Excel VBAで一発目のコード実行が遅いと感じる事が有ります。それは関係するのか？

Ｑ２．標準モジュールは分けますか？

　補足
　　　　一つに纏めれば早いとかメモリ食わない等の利点は有りますか？
　　　　APIの定義も一緒に書いてるが速度は変わってしまわないか？
　　　　どう書くのがスマートなのか。。。。

回答No.3

tsukasa-12r

私の場合、自分しか使用しないものについては、次のようにしています。

コマンドボタンクリック時の処理については、そのシート、または、フォーム等でしか使用しない処理ならば、ある程度の長さまでは、コマンドボタンクリック時のイベントプロシージャに記述してしまいます。
機能追加などでどんどん記述が長くなって見にくくなってくると、Sub プロシージャや Function プロシージャを使用して処理を分割し、イベントプロシージャの処理の流れがわかりやすいようにします。
このとき、Sub プロシージャや Function プロシージャが、そのシート、またはフォームなどでしか使用しないのであれば、そのプロシージャを、そのシートなりフォームなりの中に記述します。
また、いろいろな xls で使用する処理は標準モジュールに記述します。

API についても、そのシートやフォーム等でしか使用しないのであれば、そのシートやフォームで宣言してしまいますが、あちこちいろいろな API を使用する場合、API の宣言だけの標準モジュールにまとめます。
API 関係で、VBA の仕様上、標準モジュールにしか記述できないものとしてコールバック関数 ( ウィンドプロシージャ等 ) があり、コールバック関数とセットで使用する API は、同じ標準モジュールにまとめておきます。

Sub プロシージャと Function プロシージャの違いについてですが、戻り値があるかないかの違いだけで、処理速度に大差はないと思います。もちろん、Function の方は戻り値を返す処理が行われますので、その分、Sub に比べて処理内容が多くなりますが、通常、体感できるほどの差異はないのではないかと思います。

一回目の処理が遅いのは、VBA に限らず、プログラム全般に言えることではないでしょうか。なぜそのようになるのかについては、「キャッシュとは」で検索して調べてみるとわかると思います。

回答No.2

Wendy02

こんにちは。

Excel VBAが対象なのでしょうか？Access VBAでしょうか、それぞのアプリケーションによって違ってくるものがあります。一般論では語れない部分があります。

Excelのモジュールですと、一応、プログラマーズ・ルールのような決まりがあったはずで、どこかで読んだ覚えがあります。

>コードを書く場所で一般的なのは、ボタン内or一般モジュール内のSubそれともFunction？

コマンドボタンなら、コマンドボタンの直下に入れればよいと思います。つまり、イベントを用いる場合は、シートなどのローカルモジュールに入れます。管理しやすいからです。もちろん、秘匿化させるなら、クラスモジュールを用います。

標準モジュールは、マクロをグローバル化させるためのものですが、Excelは、シートなどがローカルモジュールが多数あるがために、標準モジュールを利用します。Function プロシージャは、Excelではほとんど使用しません。Excelは、ユーザー定義関数を用います。ここが、Excel VBA独特の特徴です。

>Excel VBAで一発目のコード実行が遅いと感じる事が有ります。それは関係するのか？
>Functionにすると早いが、メモリに残ると予想しますが、どうでしょう？

Function プロシージャではなくて、ユーザー定義関数のことだと思いますが、オブジェクト自体はメモリには残りません。メモリの最初は、Excel全体が、メモリを確保してからプログラムが働きますが、最初は確保されていないからです。

>　APIの定義も一緒に書いてるが速度は変わってしまわないか？
APIとは、Win32APIのことだと思います。API自体は、VBAでは、他のAPIも使用します。例えば、SAPIがあります。速度的に変わるというほどに人間の感知できるレベルではありません。それよりも、Win32APIは、ワークブック全体で用いるなら、必ず、別途、標準モジュールにまとめます。

>一つに纏めれば早いとかメモリ食わない等の利点は有りますか？

メモリがどうかはというなら、根本的に考え方が違います。通常、実行時は、すべてコンパイルされて中間言語として置かれます。だから、常にメモリ上に存在します。特に、Range型のオブジェクトなどは、ワークシート側のRangeやオブジェクトと連結しています。だから、そのままでは、メモリ食いというのは、避けられません。複数書けば複数のRange のオブジェクトを監視した状態で置かれます。確か、ワークシートに書き込む数式も、ワークシートを監視しているはずです。そのようなメモリを圧迫するほどのマクロは、入門以下の素人マクロでしかありませんが。

Subプロシージャの内容によってまとめます。関連性のあるものを同じモジュール内に入れます。まったく別々のものを同じモジュールには入れません。

そうは言っても、VBAでは、あまりしませんが、別のブックと参照設定によってつなぐと、プロジェクト・グループになってしまう可能性があります。そうすると、管理しにくくなりますから、つなげて使う場合は、アドインなどのほうが楽です。

補足

回答有難う御座います。

＞Excelは、ユーザー定義関数を用います。

Function＝ユーザー定義関数
となり、ワークシートからも呼べてしまうので
Subプロシージャを使う方が適切と思い、

コマンドボタン内にコードを書く様にしました。

ただ、i,j,kみたいな変数をプロシージャ毎に、毎回Dim定義するのが気に入りません。
標準モジュールでPubricで定義するとスッキリして見易くなりすが、
標準モジュールに書くと他のSheet、他のWorkBookからも呼べるので止めました。

考え方が間違っていればお教え下さい。宜しくお願いします。

回答No.1

tyosu

あくまで参考までに。
Q1 . 人によってまちまちだと思いますが、私は基本的に
標準モジュール内に処理を書いて、ボタンには戻り値があるなしにかかわらず、メソッドの呼び出しと最小限の処理（値の変更）などで済ませています。
そのほうが後からプログラムの改造をするときに追いやすいからです。
VBAについてはよくわかりません。ごめんなさい。

標準モジュールはある程度部類（宣言・表示など）に分けておくと解析・改造が安易なコードになるとおもいます。

あくまで解析・改造が安易なプログラミングを目指しているので、処理は必ずしも速いとは限りません。。。。