管理プログラムを自作しようとする人は、その時点で何らかのソフトを使用しているはずです。使用しているソフトに不満があり、新しい機能を追加あるいは修正するのに費用がかけられないために自作を検討する場合がほとんどだと思います。実際、自分もそうでした。
作成するフォームの構成は使用中のプログラムのフォームを参考にして似たようなものを作成していくことになります。
しかし、コードの部分は外注で作成したものなら見せてもらうこともできないし、コードそのものがないような環境で作成されているかもしれません。私の場合は、以前使用していたプログラムはdbMagicで作成されていました。dbMagicはよく知りませんが、どうもコードがない開発環境のようでした。
そういった場合、作成するファームのイメージはあるし、だいたいどういった風にプログラムを組めば良いかもわかるけれど、それが今後作成していくプログラミングスタイルとして適当なのかどうか、開発の始めの段階でよくわからないと思います。
プログラム開発会社なら、長年の経験からプログラミングスタイルも決まっているでしょうし、こういったプログラミングは禁止、とかいった社内ルールもハッキリしていることでしょう。
しかし、自作プログラマーはそんな経験もなければ、指導してくれる人もありません。数冊のプログラム教本を読んだ時点でとりあえず作成を開始することになります。
そこがかなり不安なところです。「作ってはみたものの途中でいきづまってしまい、最初からまたやり直しになってしまうんではないか?」そういった危惧はぬぐいきれません。
まあ、実際やってみると何とかなるもんで、とりあえず製作するわけですが、やはり、最初によく考えておいた方が良いこともあります。
それはフォーム、クエリー、レポートの名前付けです。私の場合、フォーム名はそのフォームを開くコマンドボタン名の順にすることにしました。
例えば、販売管理プログラムを立ち上げた時、最初に開くフォームは「m」です。その次に「m」フォームの「cmd18」ボタンを押して開いたフォームは「m_cmd18」です。さらに続けて「m_cmd18」フォームのファンクションキー「F7」(コマンドボタンcmdF7に割り付けてあります)を押して開いたファームは「m_cmd18_f7」です。
クエリー名、レポート名はフォーム名の頭に「q」、「r」を付けています。例えばクエリーがフォーム「m_cmd18_f7」のレコードソースになる場合は「q_m_cmd18_f7」だし、そのレポートが「m_cmd18」のファンクションキー「F7」をクリックした場合に印刷されるものなら、「r_m_cmd18_f7」です。そのレポートのソースとなるクエリーなら「q_r_m_cmd18_f7」です。
この方法で特に破綻せずに製作しています。
ただし、例外もあります。商品選択画面だとか、得意先選択画面といったフォームは頻繁に使用するフォームで、どのフォームからも開く可能性があります。そういったフォームだけ仕方ないので、「s_shouhin_sentaku」とか「s_tokuisaki_sentaku」とかしています。メニューから呼び出しすフォームは頭に「m」が付くし、選択専用フォームは「s」が付くのでナビゲーションウインドウで一覧表示した時にわかり易いです。