MSDN2 ライブラリに VB のコーディング規約 (標準) がありますが、個人的に異議を唱えたいと思います。あくまで個人的な異論であり、私のメモ代わりです。
Main メソッドを使用するときには、新しいコンソール アプリケーションの既定の構造を使用し、コマンド ライン引数には My を使用します。
.NET Framework クラス ライブラリや Visual Basic ランタイム ライブラリよりも My の機能を使用します。
無理に My を推奨する必要はないと思います。個人的にはむしろ、My は使わないでくださいにしようと思います。せっかく .NET Framework Class Library で統一感が出ているだけに勿体ないです。
クラスの海に溺れないように My が登場したとのことですが、My が登場することによって、また覚えることが増えて余計にクラスの海に溺れることを危惧しています。
そもそも、はじめはクラス内のメンバをすべて覚える必要はありません。どんなクラスがどの名前空間に属しているかを何となく覚えておけば、インテリセンスやリファレンスですぐ使いたいものは調べられます。その方が覚えやすいでしょう。また今後のためにもなります。My ですべてカバーしているわけではなく、結局 .NET Framework Class Library も覚えていかなければなりませんから。
.NET Framework クラス ライブラリはサービス指向ですから、慣れてしまえば、はじめて使う機能もどのあたりにあるか予想がつくようになります。VB をそこそこやっているプログラマであれば、VB 専用の関数を 9 割くらいは覚えているハズです。そのような方が、名前空間とクラスを覚えられないとは私は思いません。それとも、自分たちで決めた名前空間の階層がわかりにくいと言うのでしょうか...
配列指定子は、次のように、型ではなく変数に指定します。
Dim letters() As String = {"a", "b", "c"}
次のような記述は避けます。
Dim letters As String() = {"a", "b", "c"}
.NET CLR では、すべての型で配列にすることができます。配列は、System.Array から派生した型になります。ですから、型に配列修飾子である "()" を付けた方が、私はわかりやすいと思います。.NET CLR は型を強く意識しておりますからね。
VB6 時代では仕方なく変数名に配列修飾子を付けていました。しかし、VB6 時代でも関数 (メソッド) の戻り値については「型」につけるしかなかったですよね。この時点で「揺らぎ」があるわけですから、統一すべきだと思います。
1 つのオブジェクトに対する呼び出しが続く場合には、With キーワードの使用を検討します。
これだと、無法 With 地帯 になり兼ねないので、もっと制限事項を設けた方が良いと思います。私ならば、以下のことを盛り込みます。
- With ステートメントはネストしないこと。(With ステートメントのブロック内に With ステートメントを書かない)
- 初期化等、省略したインスタンスに対して処理が明確である場合にのみ使用すること。
- With ステートメントのブロック内が数 10 行に及ばないこと。
- With ステートメントのブロック内に With で省略したインスタンスに直接関係しない処理を記述しないこと。
- パフォーマンスが上がるなどと思い込まないこと。(VB6 以前は除く)
ここまで盛り込むとなかなか使えなくなります。そう、無理に使う必要などありません。省略すると返って見難くなるケースが多いと感じます。私は Smalltalk のカスケードさえも好きになれません。
My.Forms.Form1.ShowDialog ではなく Form1.ShowDialog を使用します。
VB2005 でウリ (?) になっている「フォームの既定のインスタンス」ですが、そもそも私は使わせません。
MessageBox.Show または Console.WriteLine の代わりに MsgBox を使用します。
.NET Framework クラス ライブラリよりも Visual Basic ランタイム ライブラリを使用します。
いやですw 統一感を出すためにも、.NET Framework Class Library を優先して使用します。