私は、プロジェクトの開始時に「VB.NetまたはC#を使用すべきか」という質問が提起された職場にいました。
確かに、特に言語の収束への傾向を考えると、.Netの初期の頃よりも、今すぐその決定を下す必要があるのはおそらく一般的ではありませんが、それでも激しい議論になる可能性があります。
VB.NetとC#の間では、どの言語を好むのですか?
私は、プロジェクトの開始時に「VB.NetまたはC#を使用すべきか」という質問が提起された職場にいました。
確かに、特に言語の収束への傾向を考えると、.Netの初期の頃よりも、今すぐその決定を下す必要があるのはおそらく一般的ではありませんが、それでも激しい議論になる可能性があります。
VB.NetとC#の間では、どの言語を好むのですか?
回答:
VB.NETよりもC#の方が好きです
(stackoverflowから)
VB.NETが嫌いです。まだそれを使って過ごしている日は、私が後悔している日です。とは言っても、私の好みは私の状況と経験の一部であり、あなたがしていることとは必ずしも関連性がありません...
C#やVB.NETのように絶えず進化する言語を比較するとき、それらの歴史を振り返り、現在の状態に到達した方法を確認することが重要だと思います。
マイコン上のBASICの元々の利点には、サイズとシンプルさ(小さくて合理的な高速インタープリター用の構文解析しやすい小さな構文、および実際のプログラムとデータ用のメモリの空きスペース)、実験を可能にするインタラクティブ環境、および構文が含まれていましたそれは合理的な明確な英語のような構文のために簡潔なシンボルと構造を避けました。ただし、大規模で構造化されたプログラムにはあまり適さず、スパゲッティコードを推奨する傾向がありました。それでも、その可用性とシンプルさにより、プログラミングの入門に最適な選択肢となりました。
QuickBasicは構文を更新して、構造化された大規模なプログラムを許可し、実行を高速化するためにコンパイルを追加しました。
VisualBasicは、GUIアプリケーションの迅速な構築を可能にする強力で使いやすいフォームビルダーを提供し、これらのUIのスクリプトで使用するためにQB構文を採用しました。事前に構築されたコンポーネント(通常は他の言語で記述されている)として提供される低レベルロジックのUIを作成するのに使用すると、最もうまく機能しました。時間が経つにつれて、新しい機能が追加されるにつれて、構文はますます大きくなり、一貫性がなくなりました。UIを最初に作成してからスクリプトの一部を入力することに焦点を合わせることは、小さなUI中心のアプリではうまく機能しましたが、再利用や複雑なデータ構造を思いとどまらせながら、コピーペーストプログラミングとスパゲッティコードのバリエーションを促進する傾向がありました。関心事の分離。多くの人の心の中では、「VBコード」は「泥の大きな玉」と同義語になりました。「経験の浅いハック」を持つ「VBプログラマー」。
VB.NETは、.NETプラットフォーム上のVBに似た言語であり、大きくなりすぎたVB構文をクリーンアップおよびモダナイズする試み(完全に成功したわけではありません)。既存のVBコードとの完全な互換性はなく、VB フォーム(おそらくVB の最も重要な部分)との互換性を提供する努力は一切行いませんでした。これにより、多くのVB製品所有者は、VB.NETでアプリケーションを効果的に書き直す(慎重に検討されなかったすべてのルーチンで微妙な非互換性に対処する)か、実際にC#でアプリケーションを書き直す(不慣れな人に対処する)に加えて構文新しいランタイムライブラリとフォームデザイナー)。ほとんどのVB.NETユーザーはVBユーザーであり、構文だけにこだわっており、多くの人がC#の学習中に松葉杖として使用しています。その結果、それはすぐに、彼らの方法で立ち往生し、スキルを拡大または改善することを望まない、またはできないプログラマーの避難所としての評判を取りました。
この時点で、VB.NETは進化を続け、新しい興味深い構文(LINQ、XMLリテラル)を拾いながら、ゆっくりと荷物を捨てていきます。それでも、BASICの元々の利点はほとんど保持されていません。学習曲線がかなり急で、インタラクティブな実験の機会が限られている大規模で複雑な言語です。
私は両方に精通していますが、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#を使用していれば、少し有利なスタートが切れるという事実が気に入っています。
name
を持つコンストラクター内のパラメーターと名前を持つパブリックプロパティを持ち、Name
それを介して割り当てることは、世界にとって意味のあることName = name;
です。あなたがコーディング標準を維持している限り、そうでなければ同意しますが、それは混乱を引き起こす可能性があります。
私は、Cスタイル言語のブラケット構文を、BASICスタイル言語のより「冗長」な構文よりも好みます。
プログラミングの私の紹介は、Turbo Pascalについてでした。(私がCommodore 64で子供の頃に行ったBASICプログラミングのビットは、実際には重要ではありません。)Javaを学習した後、私は振り返ることなく、Cスタイルの構文を好みました。
if something then code endif
機能的には同じで、一方ではできないこと、もう一方ではできないこと、そして将来マイクロソフトは言語チームが両方を均等に開発することを約束しているため、これは同等ではないでしょう。
違いは現在、純粋に文化的で個人的なものです。この記事は、C#とVB.netを使用するプログラマーの文化の違いに関する興味深い記事です。
[注:私自身はC#開発者ですが、リンクされた記事の結論は必ずしも私の個人的な意見を反映しているわけではなく、議論における興味深い代替アプローチにすぎません]
私は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派生言語でほぼ同じです。構文はとにかくすぐに学ぶことができるものなので、これは私にとって転換点ではありませんが。
Object.ReferenceEquals
ほぼ適切に行われるイベント処理、およびよりスムーズなIDEエクスペリエンスを提供します。VB.netを使用すると、フィールドイニシャライザーがコンストラクターパラメーターIDisposable
を使用したり、ThreadStatic
変数を使用せずにオブジェクトを安全に作成したりすることができます。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#でこの線を引くアドインがありますが、Microsoftには再び、相互に対話しないac#チームと視覚的な基本チームがあります。
vb.netでは、winformを作成するときに、エディターの上部にあるVisual Studioに2つのコンボボックスがあり、適切なコンボボックスでイベントを選択すると、イベントを自動的に生成できます。毎日多数のイベントを添付する場合、この機能がないと非常に面倒です。c#では、プロパティグリッドの上部にイベントを生成できる小さなボタンがありますが、vb.netのように高速ではありません。さらに、C#でコントロールのイベントを添付してフォーム上のコントロールを削除した場合、イベントを処理するために自動生成コードで作成されたデリゲートは手動で削除する必要があります。再びマイクロソフトに感謝します。
vb.netでは、クエリ自体を変更せずにlinqクエリを含むメソッドを変更しようとすると、C#では問題なく、すべてのメソッドコードがロックされます。多くのlinqクエリまたはラムダ式がある場合、編集および続行機能はすぐに古くなります。少し誇張しますが... :)
vb.netでは、メソッド名を作成してEnterをタップすると、「サブ終了」が自動的に作成されます。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#に変換することにしました。私はオブジェクト指向、デザインパターン、標準と厳格な構文を使用したクリーンコードのすべてのベストプラクティスを使用してプログラミングを行います。コードを他のベストプラクティスなしでc#で変換し、別の人になります。あなたが尊敬しなければならない素晴らしい男..... :(なんて冗談... !!!しかしそれは現実です。
SOとCodePlexの間で、どの言語がより人気がありますか?C#またはVB.Net?
時々、群れをフォローするのは良いことです。なぜなら、それが必要なときにあなたを助けることができるのは群れだからです。デフォルトでは、C#はVb.Netよりも高速です。ただし、Option Strictを使用すると、イコライズされる可能性があります。最後にILを2つで比較したとき、VB.Netの型安全性は最終的にILを約15%増やしました。これは余分なオーバーヘッドに変換されます。そして...基本的に同じことをする言語が与えられた場合、より高速な言語を使用します。私の利便性は、一般的にユーザーのエクスペリエンスをオーバーライドするべきではありません。
BASICがまだ人気がある唯一の理由は、それがMicrosoftの最初の製品であり、過去35年間、彼らが喉を痛めつけてきたということです。それはずっと前に死んでいたはずです。
とはいえ、私は2つのかなりの.NETプロジェクトに取り組んできましたが、両方ともVB.Netで行われました-ただし、翻訳がビッチであるか、VB.Netにコンストラクトが存在しないため、C#が少しありました。私がVB.Netで見る唯一の利点は、Visual StudioエディターがC#よりもはるかに使いやすいことです(私の経験では)同様に、IDEの構成に何か不足しているだけかもしれません...)
VB.Netの主な欠点は、VB6コードの変換を容易にするために、.NET 1.xに多くのVB6-era時代の方法を取り戻したことです。そのようなものはまだそこにあり、VB6コーダーは、より中立な.NETクラス/メソッド/その他を使用するのではなく、それらの「拡張」を使用して新しいコードをコーディングしています。なぜ上司にまだそのがらくたを使っているのか聞いたことがありません。「しかし...うまくいく...」そうです。ねえ、私は雌犬が好きです。
Webでのヘルプを探していると、ほとんどのソリューションがC#にあることがわかりました。MSDNフォーラム、さまざまなブログなどをチェックしてください。本はC#に焦点を当てる傾向があり、VBバージョンがある場合は、通常は数か月後に来ます(例:Pro LINQ .... Apressから。)
多くの言語がCの祖先を共有しているため、C、C ++、C#、Java、PHPなどを簡単に切り替えることができます。PHPはここでは少し拡張されていますが、Cのような構造がたくさんあります。VB?まあ、それはほとんどそれ自身の小さなものであり、それはそれです。
私の組織のプロジェクトリーダーは最近、VBの代わりにC#を使用して、ますます多くの新しいプロジェクトが開発されていると言いました-最終的に。私たちの組織に.NETが導入されたとき、すでに行われていたすべてのVB6コーディングのために、彼らは多少なりとも公式にVB.Netを使いました。それが彼らの最高の動きではなかったと後で認められる力。
上記の他の誰かが指摘したように、私はVB.Netプロジェクトにノーとは言いませんが、私の職場での新しい開発からゆっくりと根絶されることを望んでいます。
さて、今日、VB.netを使用する本当の理由はほとんどありません。当初は、VBプログラマーに使い慣れた構文を提供する方法でしたが、基本的にはC#のBASICのような再マッピングでした。したがって、唯一の本当の利点は、より馴染みのある構文であり、そのBASIC構文も本当の唯一の制限です。
2つの言語が一緒に進化してきた間、唯一の重要な違いはmy
疑似名前空間です。
コミュニティはかなり大きく、Cに似た構文はほとんどの使用言語に共通しているため、C#に慣れていないすべての.netプログラマーに学習することをお勧めします。
C#よりもVB .Netの方が好きです。