こちらのエントリで、僕がVB嫌いだということを書いた矢先。こちらにもVB嫌いな方がおられました。
http://forza.cocolog-nifty.com/blog/2005/11/post_d29d.html
・型チェックが弱い。コンパイルしても、実際に動かさないと、コンパイルエラーすら見つからない！！
・実装継承がないのでポリモルフィズムが使えない。Case文がやたらと多い。
・例外処理がないので、GoTo文を使うしかない。
・Formに全てのロジックを書いてしまっているために、シーケンス図で書くと、肥大化したクラスそのものになってしまう。
・クラスを使うロジックが少ないため、関数の引数がやたらと長い。
・関数の引数に戻り値を渡す書き方が多いため、混乱しやすい。
・VBはFTP等のネットワーク系ライブラリが使いづらい。
・Collection等のコンテナのライブラリの機能が少ないため、基本的なアルゴリズムをわざわざ実装する手間がかかる。
うん、やっぱりVBを不便に思う人は簡単に見つかるんだ。
・実装継承がないのでポリモルフィズムが使えない。Case文がやたらと多い。
VBは純粋なオブジェクト指向言語ではなく、継承をサポートしていない。インターフェースクラスを作成することは可能だが、スーパークラスに実装を記述できないため、OOしようとするといびつなプログラミングになってしまう。
・例外処理がないので、GoTo文を使うしかない。
エラー処理といえば、僕は元々VBのOn Error GoTo…しか知らなかった。始めてJavaをコーディングしたときは、try…catch句の便利さにビビッた。というか、VBが不便すぎることをまざまざと思い知った。
それはそうと、僕の会社で、VB→VB.Netに移行した時のことだが頑なにOn Error GoToを使い続けている人がいた。 おまえは進歩せんな、と思ったわけですが。
・Collection等のコンテナのライブラリの機能が少ないため、基本的なアルゴリズムをわざわざ実装する手間がかかる。
まったく…Collectionは貧弱です。配列を使う場合もJavaとは違い「配列オブジェクト」ではないので、「UBound」といった関数を使わなければならないし。しかもこれでエラー発生って言われても…
Dim intArray() As Integer MsgBox CStr(UBound(intArray)) '無理っす
この宣言の仕方だと配列をRedimしてやらないとUBound関数に入れた時に落ちてしまう。なんだか、「いつ生成されたのか」や、「要素数はいくらか」を調べる手段や、それらを適用可能なタイミングを適切にするには非常に面倒だ。Javaならば配列はオブジェクトなのでインスタンス化されたかどうか調べたり、配列の上限を調べるのは配列オブジェクトのインスタンスメソッドを使えば簡単だ。オブジェクトが存在するかどうかはnullと比較すればいいわけだし。
これらを振り返ってみると、面倒とかいびつという単語がよく出てくる。
そうなんだ。これはつまり、VBで書かれたコードは読みづらいということなんだ。
