良いソースを組むには (ID:75284)

名前

ホームページ(ブログ、Twitterなど)のURL (省略可)

本文 ① 基本的に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処理 等は良くない。 データ表示だけの関数 入力不可制御だけの関数(前の関数で表示した値を判定) の方がメンテしやすい 個人差はあるかもしれません。 良いソースを作るには手間（工数）が必ずかかります。 お仕事の内容によりうまく使い分けましょう。