トップ回答者
VB2005 ソースコード文字列の置換方法?

質問
-
会社の環境が、従来VB6でしたが、VB2005に移行しました。それに伴い、クラスを使ったソースになりました。
これで困ったのが、1行のコードが長くなることです。例えば、こんな感じです。
<従来> iABC(iAddr) = &H1200
又は SetABC(iAddr, &H1200)
<今後> gmPara.SetPara(enumNo.ABC, iAddr, &H1200)
現状のVB2005は、他の人が予めクラスを定義してあるので、もっと長くなっています。
これを、C言語での#defineのようなもので、もっと短く作成できないかと考えました。
<例>
#define SetP gmPara.SetPara
#define enABC enumNo.ABC
上記のように短縮した名前で定義できれば、各処理箇所は短縮表記できて、
実行時(コンパイル時)は、本来の関数・変数名で実行されるんじゃないかなと。
VB2005で、C言語の#defineのような使い方のできる方法をご存じないでしょうか?
回答
-
外池です。
このあたりの議論は、プログラミングの現場の方々の「慣れ」の問題とは思えません。それよりもプログラムの部分、部分の「性質」に依るものだと思います。
この業界は変化が激しいもので、プログラマの慣れよりも、開発環境(言語仕様も含めて)の変化が先行してしまいガチで大変なのはわかるのですが、大事なことは、古いスタイルのままで仕事をしてしまっても(できてしまっても)、将来どこかでツケが回ってシンドイ思いをしてしまいますので、他の方々のご意見は十分に参考になさってください。
プログラムの部分、部分の「性質」、と申し上げたのは、要するにオブジェクト指向なプログラミング・スタイルが必要なところと、そうでないところと、分けて考えれば良い、ということです。
私は数値計算分野の仕事が多いので、数学的な解法を実装したルーチンをよく扱います。アルゴリズムは非常に複雑ではありますが、全然オブジェクト指向っぽくありません。変数名ができるだけ短く、演算子や数値関数の関係が読みやすい(理論の数式と対比しやすい)ことが求められますので、Aliasの類は非常に便利です。(こちらは、MHINOさんと比較的似た状況があって、極端な話、FOTRANのソースコードや、古いNEC-PC時代のNxx-BASICのソースコードからCopy&Pasteして使ったりします。)
一方で、Windowやコントロールを使ったGUIをプログラムする場合は、大抵オブジェクト指向ですので、私も他の方と同様で名前は正確に読めるように省略しないほうが良いと思います。んで、実態・・・、VB6からの移行では、ほぼ、全面的に書き直していました。(VB2003からVB2005の移行でも、コードの流用はやりますが、コントロールの配置などは、全面的にやり直してました)
-
お騒がせしました。質問した本人です。
スレを閉じてなかったようです。これにて〆ます。
十数年かけて改良してきたVB6のGUIプログラムを、会社のスケジュール上、VB2005へ半年で移植することになりました。単純に開発環境の移行だけでなく、I/Oやハードウェアやネットワークの変更も含んでいますので大変なことと認識しています。
VB2005に詳しい人が一人いて、その人が全ソースを統括確認しています。私たちはかき集められた人間で、とりあえずのソース作成方法だけ知らされています。クラスやオブジェクト指向を純粋に理解する時間が取れていません。つまり、手続きさえ分かれば良いという状態です。
本当は時間をかけて理解したいのですが、VB6の全ソース(約10MB)と同等レベルを数人・半年でVB2005上に構築するため、まずは「慣れ」ることが問題でした。
最近やっと、長い名前や手続きに慣れてきましたが、まだまだソース作成に時間がかかります。時間を置くと忘れる為です。
#defineのような書き方をすれば、いつでも、文字列の置換によって、本来の姿に戻すことが出来ますので、可読性の問題は解決すると思っていました。ただし、Importsが理解できず、結局Importsを使っていません。
しばらくは、目の前の業務に追われて、真の理解はずいぶん先になると思います。この先VB2005をずっと使い続けるか、もしくは会社全体でVB2005に移行していくことが明らかになれば、それまでにできるだけ、経験者として理解を深めようと思っています。色々理不尽なことを言っていますが、ご理解いただければ幸いです。
すべての返信
-
長いままの方がわかりやすいパターンも多いので、簡素化 == 読みやすいとは思っていません。
名前が衝突しなければ良いという問題ではなく、万人対象の可読性を重視すべきです。
よって何でもかんでも簡素化することが良いと思えないので C# の using 以上の機能はあまり好きではありません。
(VB の Imports はクラス名まで省略可能にするから嫌いです)
まどか さんからの引用 残念ながら、名前空間にAlias名をつける機能しかありません。 逆に、「インスタンス」という概念を考えれば、できないこともお解かりになるかと思います。
元質問を見る限りではインスタンスはあまり関係がないように思えますが、どういうことでしょうか?
(メソッドのという意味では関係あるかもしれません)
むしろインスタンスだからこそ、参照をコピーすることによって短くすることが可能だとも言えると思います。 -
考えさせられるコメントでした。
すでに慣れている方にとっては、Importsされていると、
読みにくいと感じるのでしょうね。
私のようにクラスに慣れてないものにとっては、逆に、
関数名・変数名が短い方が、早くソフト作成できます。
実はVB2005が、今年夏くらいから使われ始めたので、
課内でも使いこなせる人は1人くらいです。
他の数人で分担してソフトを作成しています。
一応、各フォームごとに、
使用するパラメータのクラスを分けてあるようなので、
「あなたはこのクラスの関数・変数・Enumを使ってね。
先頭にImportsしておいたから。」
というように、不慣れな人へ事前説明があれば、
私のように、いちいち「どのクラスだっけ?」「どのメンバ?」
と悩むような手間が減ると思ったのです。
Alias設定後も、コードの置換をすれば、本来の名前に
戻せるのかなと思っています。
メンバーが慣れてきたら、その方がいいかなと思います。
-
外池です。
このあたりの議論は、プログラミングの現場の方々の「慣れ」の問題とは思えません。それよりもプログラムの部分、部分の「性質」に依るものだと思います。
この業界は変化が激しいもので、プログラマの慣れよりも、開発環境(言語仕様も含めて)の変化が先行してしまいガチで大変なのはわかるのですが、大事なことは、古いスタイルのままで仕事をしてしまっても(できてしまっても)、将来どこかでツケが回ってシンドイ思いをしてしまいますので、他の方々のご意見は十分に参考になさってください。
プログラムの部分、部分の「性質」、と申し上げたのは、要するにオブジェクト指向なプログラミング・スタイルが必要なところと、そうでないところと、分けて考えれば良い、ということです。
私は数値計算分野の仕事が多いので、数学的な解法を実装したルーチンをよく扱います。アルゴリズムは非常に複雑ではありますが、全然オブジェクト指向っぽくありません。変数名ができるだけ短く、演算子や数値関数の関係が読みやすい(理論の数式と対比しやすい)ことが求められますので、Aliasの類は非常に便利です。(こちらは、MHINOさんと比較的似た状況があって、極端な話、FOTRANのソースコードや、古いNEC-PC時代のNxx-BASICのソースコードからCopy&Pasteして使ったりします。)
一方で、Windowやコントロールを使ったGUIをプログラムする場合は、大抵オブジェクト指向ですので、私も他の方と同様で名前は正確に読めるように省略しないほうが良いと思います。んで、実態・・・、VB6からの移行では、ほぼ、全面的に書き直していました。(VB2003からVB2005の移行でも、コードの流用はやりますが、コントロールの配置などは、全面的にやり直してました)
-
Hoshinaです
こんにちは
じゃんぬねっと さんからの引用 元質問を見る限りではインスタンスはあまり関係がないように思えますが、どういうことでしょうか?
ちょっとだけ気になったものですから,横から口をはさみます。
元の投稿では,以下のようになっていました。
#define SetP gmPara.SetPara
ここで,「gmPara」はインスタンス変数名,「SetPara」はメソッド名と思います。
つまり,「インスタンス変数名+メソッド名」全体を別の文字列で置換したいのが希望と読みました。
インスタンス変数名はそれこそ,実装の都合でさまざまな名前をとることになります。
もしこのようなことが可能であっても,インスタンス変数名が隠されてしまっては可読性やデバッグに支障が大きいと思います。
まどかさんの投稿をこのように読みました。
-
お騒がせしました。質問した本人です。
スレを閉じてなかったようです。これにて〆ます。
十数年かけて改良してきたVB6のGUIプログラムを、会社のスケジュール上、VB2005へ半年で移植することになりました。単純に開発環境の移行だけでなく、I/Oやハードウェアやネットワークの変更も含んでいますので大変なことと認識しています。
VB2005に詳しい人が一人いて、その人が全ソースを統括確認しています。私たちはかき集められた人間で、とりあえずのソース作成方法だけ知らされています。クラスやオブジェクト指向を純粋に理解する時間が取れていません。つまり、手続きさえ分かれば良いという状態です。
本当は時間をかけて理解したいのですが、VB6の全ソース(約10MB)と同等レベルを数人・半年でVB2005上に構築するため、まずは「慣れ」ることが問題でした。
最近やっと、長い名前や手続きに慣れてきましたが、まだまだソース作成に時間がかかります。時間を置くと忘れる為です。
#defineのような書き方をすれば、いつでも、文字列の置換によって、本来の姿に戻すことが出来ますので、可読性の問題は解決すると思っていました。ただし、Importsが理解できず、結局Importsを使っていません。
しばらくは、目の前の業務に追われて、真の理解はずいぶん先になると思います。この先VB2005をずっと使い続けるか、もしくは会社全体でVB2005に移行していくことが明らかになれば、それまでにできるだけ、経験者として理解を深めようと思っています。色々理不尽なことを言っていますが、ご理解いただければ幸いです。