VB.NetとC＃の議論
私は、プロジェクトの開始時に「VB.NetとC＃のどちらを使用すべきか」という質問が出された職場にいます。
確かに、特に言語の収束への傾向を考えると、.NETの初期の頃に比べて、今その決定を下す必要があることはあまり一般的ではありませんが、それでも依然として激しい議論になる可能性があります。
それで、VB.NetとC＃の間で、どの言語が好きで、なぜですか？
VB.NETよりもC＃の方が好きです。
- プログラマ/ジョブを見つけるのは簡単です：
- ヘルプを見つけるのは簡単です：
（stackoverflowから）
VB.NETは嫌いです。今でも使っている日は後悔する日です。そうは言っても、私の好みは私の状況と経験の一部であり、あなたがしていることとは必ずしも関係ありません...
C＃やVB.NETなどの絶え間なく進化する言語を比較するときは、それらの履歴を振り返り、現在の状態にどのように到達したかを確認することが重要だと思います。
マイクロコンピュータでのBASICの元々の利点には、サイズとシンプルさ（小さくて適度に高速なインタープリターのために作成された小さくて解析しやすい構文、および実際のプログラムとデータ用のメモリ内のスペース）、実験を可能にするインタラクティブな環境、構文簡潔な記号と構造を避け、かなり明確な英語のような構文を使用しました。ただし、大規模な構造化プログラムにはあまり適しておらず、スパゲッティコードを推奨する傾向がありました。それでも、その可用性とシンプルさは、プログラミング入門の優れた選択肢になりました。
QuickBasicは、大規模で構造化されたプログラムを使用できるように構文を更新し、より高速に実行できるようにコンパイルを追加しました。
VisualBasicは、GUIアプリケーションの迅速な構築を可能にする強力で使いやすいフォームビルダーを提供し、QB構文を採用してこれらのUIのスクリプトで使用します。ビルド済みのコンポーネントとして提供される低レベルのロジック用のUIを作成するときに使用すると、最も効果的に機能します（通常、他の言語で書かれています）。時間の経過とともに、新しい機能が追加されるにつれて、構文はますます大きくなり、一貫性がなくなりました。最初にUIを作成し、次にスクリプトの一部を入力することに焦点を当てたのは、小さなUI中心のアプリではうまく機能しましたが、再利用や複雑なデータ構造を避けながら、コピーアンドペーストプログラミングやスパゲッティコードのバリエーションを奨励する傾向がありました。関心事の分離。多くの人の頭の中で、「VBコード」は「泥の大玉」の代名詞となりました。 「VBプログラマー」と「経験の浅いハック」。
VB.NETは、.NETプラットフォームのVBに似た言語であり、大きくなりすぎたVB構文をクリーンアップして最新化する試みです（完全には成功しません）。既存のVBコードとの完全な互換性はなく、VB forms（おそらくVBの最も重要な部分）との互換性を提供しようとはしませんでした。これにより、多くのVB製品所有者は、VB.NETでアプリケーションを効果的に書き直す（慎重に検討されなかったすべてのルーチンでわずかな非互換性に対処する）または実際には =アプリケーションをC＃で書き直します（不慣れな構文に対処するに加えて新しいランタイムライブラリとフォームデザイナ）。ほとんどのVB.NETユーザーはVBのユーザーで、構文だけでこだわり、C＃の学習中に松葉杖として使用していました。その結果、自分のやり方で行き詰まり、スキルを拡張したり改善したりしたくない、またはできなくなったりしたプログラマーの避難所としてすぐに評判になりました。
この時点で、VB.NETは進化を続け、新しい興味深い構文（LINQ、XMLリテラル）を取り入れながら、ゆっくりと手荷物を取り除きます。それでも、BASICの本来の利点はほとんど保持されていません。学習曲線がかなり急で、インタラクティブな実験の機会が限られている、大きく複雑な言語です。
- 過去30年以上にわたってこれにこだわっていた古いプログラマーにとって、それだけに限定されない限り、これは悪い選択ではありません。
- 新しいプログラマーにとって、英語に対するVBプログラムのあいまいさがますます似ていることは、後方互換性と社会的偏見に奇妙なうなずく価値はほとんどありません。
- 新しいprojectsの場合、言語が最適化されているいくつかのタスクの1つにプロジェクトが深く関与していない限り、VB.NETは奇妙な選択です。型の悪いCOMコンポーネントとの統合（Office ...）（ただし、C＃4.0ではこの利点が大幅に減少します）、またはインラインXML生成。
私は両方に精通していますが、VB4、VB5、およびVB6で初期のプログラミング作業の多くを行いました。 .NETの両方の言語が数回の反復を経て機能のかなりの部分に収束したので、この議論は「お好きな色は何ですか」に非常に似ていると思います。
個人的に、私はさまざまな理由でどちらも好きです。
VB.NET
C＃構文の方が直感的であると多くの人が話しますが、それは非常に主観的であり、あなたが最初に知っていたことに大きく基づいています。もしあなたが完全に客観的であれば、VB.NETの構文は、他の言語の予備知識がないと仮定すれば、おそらくもっと直感的だと私は主張します。たとえば、C＃とVB.NETで同じプログラムを使用すると、プログラミングの知識がない人にとってはより解読しやすいと思います。私にはかなりはっきりしているようです。
この構文のもう1つの良い点は、ブラケットモデルと比較して、構造を閉じること（END IF、END WHILE、NEXT X）についてより明確であることです。これにより、コードが少し読みやすくなり、多くの場合、コンパイラは正確にどの行番号がコンパイルエラーの原因となっているかを正確に知ることができます。コンパイラエラーが原因でブラケット/セミコロンハントが見つからなかったことが問題から50行離れている場合は、私が何を意味しているのかわかります。
また、私の意見では、VB.NETのwin列では、比較/代入演算子として==/=が不足しています。それぞれに別個のオペレーターがあることのまれな利点は、それが作成するのに役立つすべての（時には）困難な発見を相殺することは決してありません。
最後に、プログラミング言語の大文字と小文字の区別が嫌いです。 VB=についての不満の1つは、手荷物が多いということですが、C＃はCの大文字と小文字の区別のアルバトロスを繰り越しました。同じスコープ内で2つの識別子が必要な状況にしたことがありませんVB.NETは、C＃に比べていくつかのポイントを獲得しています。
C＃
プログラマーは簡潔であることが大好きです。そのため、一般的にこの構文を好むと思います。美的魅力があるだけです。ただし、完全に実用的な観点から見ると、Java、JavaScript、C++などの言語に非常に似ているため、気に入っています。
サーバー側とクライアント側の両方のプログラミングを必要とする多くのWeb開発を行っているため、頻繁に行う必要があるため、C＃とJavaScriptを精神的に切り替える方が簡単です。
また、ほとんどの場合、JavaまたはC++プログラミングに移行する必要があった場合に、C＃を最も使用している場合は、少し先を行くことができます。当時の。
私は、Cスタイル言語のブラケット構文を、BASICスタイル言語のより「冗長な」構文よりも好みます。
私のプログラミング入門はターボパスカルでした。 （子供の頃にCommodore 64で行ったBASICプログラミングのビットは実際にはカウントされません。）学習後Java私は振り返ることがなく、Cスタイルの構文を好みました。
これらは機能的には同じですが、もう一方ではできないことは何もできません。将来的には、Microsoftは言語チームが両方を均等に開発することを約束しているので、これは変更される可能性はほとんどありません。
現在の違いは純粋に文化的で個人的なものです。 この記事は、C＃とVB.netを使用するプログラマーの文化の違いに関する興味深い読み物です
[注：私はC＃開発者ですが、リンクされた記事の結論は必ずしも私の個人的な意見を反映しているわけではありません。それは、議論における興味深い代替アプローチにすぎません]
CとC++から.NETに来たので（Java、Ada、Pascalを少し入れて）、C＃は自然な進歩でした。
必要なVB.NETの仕事があったとしても、私は断りません。
私はVB.NETで多くの作業を行いましたが、コードで何が起こっているかの要点を取得するのに十分なC＃を理解しています。私の現在の好みはVB.NETです。これは（明らかに）よく知っているためですが、詳細なBASIC構文とCスタイルの構文のどちらも好みはありません。どちらも非常に読みやすく、理解しやすくなっています。
私の同僚のプログラミングの背景のほとんどはCOBOLとVB6なので、VB.NETはチームとして私たちにとってより快適な.NET言語の選択でした。機能的には同じなので、C＃の学習を必須とする確かな理由はありませんでした。
そうは言っても、C＃を学ぶことは、間違いなく私のやることリストに載っています。
私はC＃を好みます。
私はVB.NETプログラマーとして始めましたが、時間の経過とともに、かなり多くの新機能が最初にC＃に組み込まれ、次にVB.NET（自動プロパティなど）に組み込まれることが明らかになりました。また、C＃を取り巻くコミュニティは、VB.NETのものよりもはるかに活発です。
さらに、Javaまたは同様の言語を学ぶつもりなら、C＃がより良い出発点です-構文はすべてのC派生言語でほとんど同じです。これは構文がとにかくすぐに学べるもの。
ここに掲載されている他の回答に加えて、C＃を選択しますVB C＃プログラマーはより多くの報酬を受けるためです。
どちらの言語もほぼ同じで、2つの言語を切り替えるのは本当に簡単ですが、管理者が中括弧やセミコロンの束を見ると、VBではできないことを行っているという事実を受け入れていると思います。ネットは彼らがそれを見て「私がそれを理解することができれば、それは難しいことであってはならない」と思うかもしれません。
C＃と最小限の労力でJavaを切り替えることができるため
VB.NETは完全に異なる構文です。 C＃はJavaや他の言語に似ているので、新しいことにすぐに適応できるようになります。 C＃とVB.NETの出力は実質的に交換可能であるため、C＃を使用することは理にかなっています。さらに、会社のコードがC＃である場合、Java開発者VBよりもJava開発者にC＃のコーディング方法をトレーニングできる可能性が高くなります。微妙な利点しかありませんが、微妙な点は依然として利点です。
やや古い開発者（59は「やや古い」ですか）として、まずCommodore VIC-20でBASICを学び、Turbo Pascal（v1！）を学び、大学でCOBOLを学び、14年間IBMで開発しましたメインフレーム。VB5とVB6にサイドステップする前に、Revelation BASIC（PICK BASICのバリアント）で中規模のアプリとModula-2のいくつかのユーティリティを簡単に転用しました。そして、.NETが登場しました。
私の基本的な背景のために、私はVB.NETから始めるべきだと思いました、私が物事を「古い」方法でやろうとし続けて、それが私にナッツを運転していたことを発見しただけです（そう、もっとナッツ）。私はCでいくつかの作業を行ったので、C＃を試してみて、それがどのように行われるかを確認します。そして、OMG、それは暗いトンネルから澄んだ日光に出てきたようなものでした！全く予想外。そして、私はCが「書き込み専用」言語であることを非難していました。「Cプログラマが自分のコードを書いてから6か月後に自分のコードが何をしたのか理解できなかった」あの頃可愛いと思っていた半有名小説家。
したがって、Cに少し慣れていないという理由で、C＃は、.NETプログラミングを習得するのに、はるかに馴染みのある基本的なパラダイムよりも逆説的に簡単でした。私はまだVB6が好きですが、C＃が大好きになりました。地球上で最高のプログラミング言語。
私は2001年からVisual Basic .Netで開発していますが、それが好きで嫌いです!!!
これらのポイントのプレゼンテーションの順序は、彼が私の頭に浮かんだ順序に基づいています...
Visual Studioを使用したvb.netでは、各メソッドとプロパティの間に視覚的な改行があります。多くの人にとって、c＃よりもvb.netを好むのは良い理由ではありませんが、Microsoftのc＃チームがそれを実装していない理由がわかりません。この線をc＃で描画するアドインがありますが、互いにやりとりしないc＃チームとビジュアルベーシックチームを用意してくれたことを再度感謝します。
Vb.netでは、winformを作成すると、エディターの上部にあるビジュアルスタジオの2つのコンボボックスがあり、右側のコンボボックスでイベントを選択すると、イベントを自動的に生成できます。毎日数十のイベントを添付する場合、この機能を持たないのは非常に面倒です。 c＃では、プロパティグリッドの上部に小さなボタンがあり、イベントを生成できますが、vb.netのように高速ではありません。さらに、c＃でコントロールのイベントを添付し、フォーム上のコントロールを削除する場合、イベントを処理するために自動生成されたコードで作成されたデリゲートを手動で削除する必要があります。マイクロソフトに再度感謝します。
Vb.netでは、クエリ自体を変更せずにlinqクエリを含むメソッドを変更しようとすると、問題ありませんが、c＃ではすべてのメソッドコードがロックされます。多くのlinqクエリまたはラムダ式がある場合、編集および続行機能はすぐに古き良きものになります。わかりました、少し大げさですが... :)
Vb.netでは、メソッド名を作成してEnterをタップすると、「end sub」が自動的に作成されます。 C＃では、自分で行います。わかりました。resharperまたはdevexpressがインストールされている場合、それはより良い方法ですが、なぜこれらすべての優れた機能がc＃に実装されなかったのでしょうか。
Vb.netでは、コードにエラーがある場合、エラーが自動的に表示され、修正すると、これらのエラーはリアルタイムでスタックから削除されます。 C＃では、プロジェクトをビルドして、指定されたエラーが正常に修正されたかどうかを認識させる必要があります。 C＃チームがvb.netのようにリアルタイムでエラーを確認するオプションを用意していない理由大きな解決策では、エラーのリアルタイム検証はパフォーマンスの非常に優れた最適化にはなりませんが、修正中にエラーのスタックが消えるのを見るのが大好きです。
他の人が言及したように、vb.net条件if..end if、select case ... end selectを読むのはもっと簡単だと思いますが、devexpressペインティングブラケットを使用して、私が言ったことを忘れてください。
Vb.netでは、Visual Studioに多くのバグがあります。 Visual Studio 2010で1つ言及しただけですが、 "all"ではなく "common"モードをアクティブにしている場合、インテリセンスは列挙を正しくフィルター処理しません。
Vb.netでは、静的に、c＃の代わりにvb.netを使用するプログラマが増えるため、c＃の方が学習しやすくなり、プログラミングの実践を促進することが難しくなります。
他の人が言ったように、c＃プログラマーはより多くのお金で良い仕事をするチャンスがあります。
顧客の頭では、vb.net =コードのスパゲッティを大量に使用して地下室でプログラミングする人。 c＃=うわー、あなたはとても賢いです。事実は、C＃でプログラミングしたからではなく、優れたプログラムを作成したからではなく、静的に行われたことです。
これらすべての点を考慮して、すべてのvbコードをc＃に変換することにしました。私はオブジェクト指向、デザインパターン、標準と厳密な構文を使用したクリーンなコードのすべてのベストプラクティスを使用してプログラミングしています。50年間はそのようにプログラミングできますが、コミュニティの目から見て、私は良いプログラマではありません。私は自分のコードを他のベストプラクティスなしでc＃に変換し、私は別の人物になります。あなたが尊敬しなければならない偉大な人.....：:(なんて冗談だ... !!!）しかし、それは現実です。
私の個人的な好みを脇に置きます。最近採用している（そして採用しようとしている）人物として、オフィスでこの議論があったときの一般的なコンセンサスは、VBからC＃に移行することを検討する必要があるということでした。
どうして？ C＃は市場で（とにかく私たちの周りに）蔓延していたため、採用がより簡単になり、採用がより簡単になりました。
まるで一周したようです。より多くの候補者がいるため、採用担当者がそれを望んでいるため、人々はC＃を学びます。
これを見る方法は次のとおりです：SOとCodePlexの間で、どちらの言語がより一般的ですか？C＃またはVB.Net？
時々、群れを追跡することは良いことです。なぜなら、必要なときに群れがあなたを助けることができるからです。デフォルトでは、C＃はVb.Netより高速です。 Option Strictを使用することで同等になると思います。最後に2つのILを比較したとき、VB.Netの型の安全性により、ILが約15％増加しました。これは、余分なオーバーヘッドに変換されます。そして...基本的に同じことをする言語を考えると、私はより速いものを採用します。私の利便性は、一般的にユーザーのエクスペリエンスをオーバーライドするべきではありません。
BASICが今でも人気がある唯一の理由は、それがMicrosoftの最初の製品であり、過去35年間私たちの喉に押しつけてきたということです。それはずっと前に死んだはずだった。
そうは言っても、私は2つの大きな.NETプロジェクトに取り組んでおり、どちらもVB.Netを使用して行われました。ただし、C＃が少しあったのは、変換が悪かったか、VB.Netに構成が存在しなかったためです。 VB.Netで私が目にする唯一の利点は、Visual Studioエディターが（とにかく私の経験では）C＃よりもはるかに親しみやすいことです。Intellisenseの方が優れているようで、オートフォーマットもそうです（C＃を使用していないため、同様に、IDEの構成で何かが欠けている可能性があります...）
VB.Netの主な欠点は、VB6コードの変換を容易にするために、.NET 1.xにVB6時代の多くのがらくたをもたらしたことです。それはまだそこにあり、VB6コーダーは、より中立的な.NETクラス/メソッド/その他を使用するのではなく、それらを使用して新しいコードをコーディングしています...「拡張機能」。なぜ上司にそのがらくたを使用したのか、上司に何度尋ねたのかわかりません。 「でも……うまくいく……」そうです。ねえ、私は雌犬が好きです。
Webでヘルプを探していると、ソリューションの大部分がC＃にあることがわかりました。MSDNフォーラム、さまざまなブログなどをチェックしてください。本はC＃に焦点を当てる傾向があり、VBバージョン、通常は数か月後に提供されます（例：ApressのPro LINQ ...）。
多くの言語はCの祖先を共有しているため、C、C++、C＃、Java、PHPと他のいくつかの言語との間の切り替えがはるかに簡単になります。PHPは、ここではストレッチですが、Cのような構成がたくさんありますVB？ええと、それはそれ自身の小さなことであり、それだけです。
私の組織のプロジェクトリーダーは最近、VB-最終的に、C＃を使用して新しいプロジェクトがますます開発されていると言いました。NETが私たちの組織に導入されたとき、それらは多かれ少なかれ-既に行われているすべてのVB6コーディングが原因で、公式にVB.Netに移行しました。
上記の誰かが指摘したように、私はVB.Netプロジェクトにノーとは言いませんが、私の職場での新しい開発からゆっくりと根絶されることを望んでいます。
私はVB .Net for C＃、を好みます）
- （97）...
- （98）C＃を知る前にVB=を学んだからです。
- （99）VB .Net。
- （100）VBには中括弧がないためです。
- （101）誰もがVBを嫌うから。
VB言語は初心者にとって読みやすく、最初のアプリケーション、2番目のアプリケーション、3番目のアプリケーションを記述する傾向があり、最初のアプリケーションがどのようにコード化されているかは誰でも知っています。
C++、JavaなどのプログラマーはC＃に移行しましたが、VB.NET開発者はVBA、VB、およびBASICのバックグラウンドであり、重要な非伝統的なプログラマーです。
さて、今日、VB.netを使用する本当の理由はほとんどありません。最初は、VBプログラマに馴染みのある構文を与える方法でしたが、基本的には、C＃のBASICのような再マッピングでした。したがって、本当の利点は、より馴染みのある構文であり、そのBASIC構文も、実際の唯一の制限です。
2つの言語が一緒に発展してきた時間の中で、唯一の大きな違いはmy疑似名前空間です。
コミュニティはかなり大きく、Cに似た構文は使用頻度の高いほとんどの言語に共通しているため、C＃に精通していないすべての.netプログラマーに習得することをお勧めします。
オンラインのVB.NETサンプルよりも多くのC＃コードサンプルがあるようです。 1つをもう1つに変換するのがそれほど難しいのではなく、なぜそうする必要がないのかわからないのです。
C＃。それは、私がCとJavaを使用したからです。そのため、C＃の方が読みやすくなっています。 VB.NETは以前のVBプログラマー用であるので、C＃は私用です。