良いソースを組むには
変な質問ですいません。
標準化についての意見を聞かせていただきたいのですが
仕事の開発なのですが、標準化の資料を頂き
いくつかの不明？どんなものが良いのか？
特に①なのですが、Exit Subは便利でよく使うのですが
Goto ErrExit （エラー処理へ）は使用可です。
※プロシージャの出口は二つ以上あってはいけないそうです。
①Exit Subを使用してはいけない
②標準モジュールへ組み込むプロシージャについて
③エラートラップ
皆さんのご意見・経験等をきかせてもらえませんか
良いソースに順位を付けるとしたら
1.動く事(バグの無い)
以降をお教えください。
先に言います、わたしはひともじでもきーをうたなくてすむほうほうでそーすをかいていますので…^^;
まず、Exit Sub
まああまりに出口がいっぱいあると、こんがらがってしまうようなことはあるとおもいます。
管理できると思うのならば、使ってもいいでしょうね。
とくに数行しかないプロジージャのなかでは、
わざわざ移動先をかかないといけないGoTo〜より、そのほうがいいでしょう。
次に、標準モジュール
1ミリ秒でも早く！というプログラムを作るなら、使うべきでないそうです。
まさかそんな人いませんよね^^;
ふつう、よく使う処理とか、とくにAPIをプロジージャとしてパックしておくと、
のちのち便利ですね。
おかげでうちでは、ダイアログ一個分のプログラムくらいなら半日で作れます^^;
あと、フォームにサブルーチンを作るくらいなら、標準モジュールへ…のほうが、
フォームがすっきりするかも。
(フォームって、ふつうこんがらがるものだし…)
エラートラップ。
わたしはひとつでもキーをおさなくてすむということで、行番号をつけてジャンプさせますけど、
まともな名前のラベルをつけて、ジャンプさせたほうがいいと思います。
たいしたことのないものなら、On Error Resume Nextで。
あと、標準化…って言うのなら、コメントはしょっちゅうつけておいたほうがいいと思います。
あと、プロジージャの始めには、あったほうがいいでしょうね…。
よいソース…。うちにはいいソースはないと思うので^^;わかりませんけど、
プロジージャ始めに、どう使うのかがあるといいでしょうね、
とくに標準モジュールのは。
あと、できるだけ理解できない名前をコントロールにつけない、簡潔に済ます。
うちでは、区別をつけるために、メニューの名前には日本語を使っています。
区別をつけるという意味では、日本語も使えるかもしれません。
(キーを少なくという主旨には外れますけど…)
そんなところでしょうね。
VBには便利な"参照"機能もあることだし、
プロジージャを多く使ったほうが、わかりやすいかも。
>Exit Subを使用してはいけない
勿論、Functionの中で使ってはいけません。
が、Subの中では必ず使います。
一般的なSubの書き方
Private Sub subProc()
Dim なんたら・・・
On Error Goto Err_subProc
なんたらかんたら・・・
Exit_subProc:
Exit Sub
Err_subProc:
MsgBox "Error No = " & CStr(Err.Number) & " : " & Err.Description
Resume Exit_subProc
End Sub
>標準モジュールへ組み込むプロシージャについて
原則として、特定のFormモジュール内で使うForm依存プロシージャは
Formモジュール内にPrivateで定義、複数のFormで共有する
プロシージャは標準モジュールにPublicで、が原則でしょう。
APIのコールバック関数はアドレスが固定される必要がありますから
標準モジュールに書くしかありません。
>エラートラップ。
すでに書いている通りです。
通常、関数のネストがある場合、関数の外でエラー処理します。
そのため、イベントプロシージャ以外はすべてFunctionで定義し、
何らかの戻り値(通常は成功orエラー番号)を持つように作ります。
Private Function lngFunc() As Long
Dim なんたら・・・
lngFunc = clngFale
On Error Goto Err_lngFunc
なんたらかんたら・・・
lngFunc = clngSuccess
Exit_lngFunc:
Exit Function
Err_lngFunc:
lngFunc = Err.Number
Resume Exit_lngFunc
End Sub
呼び出し側
If lngFunc() = clngSuccess Then
うまくいったときの処理
Else
失敗したときの処理
End If
① 基本的にExit Sub/Functionはプロシージャに１つ（正常ルート）
エラールートはEnd Sub/Functionと言う場合もありますが
全てのプロシージャーを作る際はSayさんの様な雛型から
始るといっても良いでしょう、
過去にコーディング基準を守っているかソースを解析する
ツールが基盤より配布されるなんて事もありました。
ElseIf使っちゃ駄目とか、カウントアップと0以外の固定数・文字
は全てConstにしろとか・・・
② 共通関数以外のプログラムのみで使用している標準モジュール
であっても↓フォームを触ったりはしてはいけません。
sWork = From1.Text1.Text
最悪でも参照を渡してあげて（共通フォーム等）
フォームにいる必要がない場合は大体標準モジュールに組み込んでます。
③ 通常のシステム開発等ではエラー処理は共通化されているはずなので
よくあるパターンは↓
private Sub Main()
OnError Goto MainErr
If DBConnect <> pcRtnOK Then
GoTo MainErr2
End if
if GetEnviron <> pcRtnOK Then
GoTo MainErr2
End if
Exit Sub
MainErr:
このプロシージャでエラーが発生した場合の
メッセージ設定になる
MainErr2:
ここに来る場合は下位プロシージャのエラー情報が
入ってるはず
エラー情報の解析・ログ出力、共通終了処理等
End Sub
どの処理でエラーが起きた明確にする為にも
全てのプロシージャを上記の様にすればエラー情報は
どれだけ下位のプロシージャでも、発生ヶ所の情報
が入るようになる。エラーの解析や終了処理は
最も上位プロシージャ（大抵はイベントプロシージャのはず）
で行う様にする。
下位プロシージャ等でEnd発行プログラム終了とかは最悪ですね
後は、モジュール構成をはっきりする。
１つのプロシージャに何でも書こうとしない。
よくありがちな悪いソースとして
テーブル項目(30個)のデータの表示を行い
表示した項目の値によりテキストを入力不可にする（そのうち10個）
と言う処理があった場合に表示したすぐ後にIF判定のLocked処理
等は良くない。
データ表示だけの関数
入力不可制御だけの関数(前の関数で表示した値を判定)
の方がメンテしやすい
個人差はあるかもしれません。
良いソースを作るには手間（工数）が必ずかかります。
お仕事の内容によりうまく使い分けましょう。
コメント行付けるだけでとても見やすくなりますよ。
①Exit Sub
まぁ、使わないに越したことは無いが、場合によりけり。
仕事で使うのでしたら他人がデバッグに携わるのだから解りやすく、
ということでしょうね。
Select Caseでパックしてしまう、というのが一番手っ取り早いのではないでしょうか。
②標準モジュールのプロシージャ
出来る限り使わない方がいいですね、私見ですけれども。
家でプログラムをする程度でしたら多用しても構わないですが、
業務として、というのであればデバッグ及び標準モジュール内での
エラーを極力避ける、という観点からこう思います。
やたらと乱発するのはよくない、というだけで、
必要最小限で配置する、というのがベターだと思います。
③エラートラップ
私はエラーハンドラ・モジュールをひとつだけ作成して、
引数により判断する、という形をとっています。
当然成否判定の帰り値を付ける処理も忘れずに。
順位を付けるとすれば
１デバッグしやすい（読みやすい）
２動くこと
３名前（Object Name）がわかりやすい
４引数はConstで定義してある
動かなくともデバッグしやすければそのうち修正が効きます。
とにかく、仕事なのだからたくさんの制限がかかることはいたしかたない
ところなので、いろいろ工夫していってください。
私も仕事で開発をしています。参考程度で。。
まず基本的にフォームは、あくまでユーザーとのインターフェイスですので
モジュールにはその機能を補完するコードしか記述しません。具体的には、
フォームやコントロールのプロパティをセットし、イベントにはメソッドを
コーディングします。フォームのモジュール中にFunctionやSub等による処理
はほとんど記述せず、すべてクラスを設計してフォームのモジュールからイ
ンスタンスを生成して、メソッドやプロハティ・イベントを利用します。
これによるメリットは、
①毎回の開発でクラスを再利用することにより、開発工数を減らすことがで きる。
②メンテナンス性の向上。(フォームのインターフェイスは、開発する物によ り変わるものの、フォームで使用するコードは同じものが多い)
③必要な時にのみメモリ確保を行うことにより、中規模以上のシステム設計
を行う場合でも、メモリ不足等が発生しにくい。
デメリットは若干処理速度が低下する点です。
標準モジュールは揮発性が高いものの、やはり上記③の問題が発生しやすい
のでほとんど使用しません。
Tomyankunさん。
非常に参考になります。
クラスはいまいち使い方がわからないのですが、
非常に便利と聞いてちょっと勉強しようと思います。
| ツイート |  |