Mr.Tです、こんにちは。
例えば、データの整合性についてのチェックルーチンを書くとき、
Private Function チェック1() as Boolean
整合性パターン１のチェック()
整合性パターン２のチェック()
整合性パターン３のチェック()
整合性パターン４のチェック()
End Function
ってかいてるんですが、
もう一つ、別のチェック２、３をかかなくちゃならないとき、
Private Function チェック2() as Boolean
整合性パターン１のチェック()
整合性パターン２のチェック()
整合性パターン４のチェック()
End Function
Private Function チェック３() as Boolean
整合性パターン１のチェック()
整合性パターン２のチェック()
整合性パターン５のチェック()
End Function
今のところ、こうやってベタに書いてます。
そういうときに、整合性パターン１のチェック、と整合性パターン２のチェック、を一つのFunctionniにまとめてみたりしたこともあったのですが、
そういう場合は、そのFunction名の名前付けに悩みます。
Private Function 整合性パターン１と２（） as Boolean
整合性パターン１のチェック ()
整合性パターン２のチェック ()
End Function
Private Function チェック1() as Boolean
整合性パターン１と２ ()
整合性パターン３のチェック()
整合性パターン４のチェック ()
End Function
Private Function チェック2() as Boolean
整合性パターン１と２()
整合性パターン４のチェック()
End Function
Private Function チェック３() as Boolean
整合性パターン１と２()
整合性パターン５のチェック()
End Function
なにしろ、そのまとめ方というのは、単なる同じ記述だから、というだけのもので、くくりだすにしても、適当な名前がつけられるものでは
ないからです。（連番なんてのはポイだ）
整合性パターンのチェック１と２は、互いに関係があるものではなく、単純に処理が一緒だから、まとめたというだけです。
まとめる＝ソースの量を減らせる
ではあるんですが、ある程度大きくなったソースになれば関係ないように思うんです。
それよりも大切なのは、Function名がいかに適切な名前であるかです。
くくりだすことで、チェック１～３の可読性が低くなるなら、それはやめたほうがよいのだろうと思ってます。
先ほどのようにくくりだした場合、その名前から処理が判断できそうか、というと、そんな名前がつけられるのであれば苦労はしないです。
仮につけたとしても、名前から判断できるものをつけられたためしがない。
また、チェック１～３をまとめたりするのは、あるかと思います
Private Enum Pattern
チェック１
チェック２
チェック３
end Enum
Private Function チェック(byval pattern as Pattern) as Boolean
整合性パターン１ ()
整合性パターン２ ()
select case pattern
case Pattern.チェック１
整合性パターン３のチェック()
整合性パターン４のチェック ()
case Pattern.チェック2
整合性パターン１と２()
整合性パターン４のチェック()
case Pattern.チェック3
整合性パターン５のチェック()
End Case
End Function
ただし、チェックという名前にしてしまうとなんのチェックなのかわからなくなってしまうケースがあることと、
一つのルーチンそのものが、長くなり一覧性が失われるってところです。
とはいえ、ここの判断はケースバイケースですし、好みもあるんじゃないかと。
私なら、チェック１という名前自体に直接結びつくメソッドがあるなら、統一しません。
例えば、
更新処理（）というメソッドがあるなら、更新処理用チェック（）をつくってしまいます。
そこには更新処理用のチェック処理しかないので、その処理を追うときには、それ以外のことを考える必要がないからです。
チェックという大きなルーチンをつかってしまったりすると、その部分を変更したときに、他のチェック２，３を行う
フローに影響がないかテストしなくてはならないから、ですね。
専用ルーチンなら、そんなことはありません。専用ルーチンだけをテストすればよいわけです。
が、他のチェック内容とほぼ一緒で、数行しか違わないとかいうパターンなら、まとめてしまいます。
なので、ケースバイケースです。
蛇足ですが、チェックルーチン内で、「～の値をセット」とかいう別のことをしたらいけません。
#意味的に処理の分割ができなかったりすると、チェックルーチンと一緒に値のセットとか、プロパティ値のクリアとか
#ごちゃまぜにしてしまうのですが、それは処理を追いきれなくなります。
チェックルーチンは判断するだけにしておくことが必須だと思ってます。
なんか、すんごいベーシックな話ですが...