成熟するにつれて、言語はより冗長になりますか? VB.net の新しいバージョンごとに、より多くの構文が追加されているように感じます。キーワード「Dim」のような脂肪を減らすことは可能ですか? C# も、バージョン 1 から構文が増えているように感じます。
16 に答える
それがVBのイディオムです。すべての言語にはイディオムがあり、冗長でスペルアウトされたイディオムがたくさんあります。あなたの幸運の星に感謝しますWRITING IN COBOL
。
&&
C# は C に似た言語から進化したもので、C の伝統では簡潔さと簡潔さが重視さ||
れint
ますinteger
。VB のイディオムでは、長い自明のキーワードは適切であり、簡潔なキーワードや不可解な記号は不適切です。したがってMustInherit
、Dim blah as Integer
大文字と小文字は区別されませんが、キーワードを大文字にする傾向があります。基本的に、使用している言語のイディオムに固執してください。VB を使用している (または使用する必要がある) 場合は、冗長性に慣れてください。これは意図的なものです。
C# では確かに構文が増えていますが、その分、冗長性が低下しています。
C# 3.0 の実質的にすべての機能により、少ないコードでより多くのことを実行できます。
冗長性に問題はありません。実際、多くの場合、それは非常に良いことです。
意味のある変数名があると思いますか?わかりやすいメソッド名? それでは、「}」の代わりに「end if」と入力すると問題が発生するのはなぜですか。それは実際にはまったく問題ではありません.C#の簡潔さは、可能な限り少ない文字にできるだけ多くを収めようとする問題です-つまり、読みにくく、簡単ではありません.
わかりました...これを認めるのは恥ずかしいことですが、VB.NET での Dim の使用が気に入っています。はい、後で「As」を使用して推測できなかった特定の用途には役立っていません...しかし、私にとっては、宣言ステートメントをDimで開始することについて、絶対に「頭を悩ませている」明らかな何かがあります。これは、誰かがコードを調べているときに、それらのステートメントが何を意味するのかをマイクロ秒でも考える必要がないことを意味します。C# などの言語には十分に明白な宣言がありますが、それを参照しているだけの場合は、少しの間 (最も短い時間であっても) 考慮する必要がある場合があります。
特定の種類のステートメントの開始時に特別なキーワードを使用することには、「非常に明白な」ことがあります。VB.NET では、割り当ては "Dim" で始まり、メソッドへの呼び出し (できます) は "Call" で始まり、If、For、およびその他の構成要素が既に持っている一種の「左側の均一性」を与えます。まさにその冒頭を見るだけで、その行で何が起こっているのかを知ることができます。これらを使用すると、左側の列とほぼ同等のものが得られ、非常にすばやくブラウズして、ある種の基本的なレベルで何が起こっているかの要点を得ることができます (「わかりました、ここで物事を宣言しています...ここで他のものを呼び出す...」)。
一部の人々にとっては、それは不合理またはばかげているように見えるかもしれません...しかし、それは各ステートメントの目的を十分に明確にし、(少なくとも私にとっては)ブラウジングするのが速く感じるようにします...特に他の人によって書かれたなじみのないコードをブラウズするとき.
最終的には「人それぞれの書き方」に行き着くと思います。目的を明確にするために、余分な 3 文字を入力してもかまいません。
多くの場合、冗長性と読みやすさは密接に関連しています。最近、私は「エレガント」という言葉を恐れるようになりました。なぜなら、それは一般的に「楽しいが、すぐには読めない」と訳されるからです。
もちろん、コードを書いている人はいつも「コードが短くてエレガントだから読みやすい。
それはがらくたです。ディックとジェーンの小説を読み終えるのに 2 時間かかるほど読むのに苦労しない限り、より露骨な内容のものを読む方が常に簡単です。
私は冗長性について話しているのではなく、明示的であり、あなたの欲求を綴っているだけであることに注意してください.
プログラマーとしては、エレガントな式を書くほうがはるかに楽しいのですが、しばらくすると、他人の「エレガンス」や自分自身の「エレガンス」に目を向けるようになり、それをより明示的で読みやすく、わかりやすいものに変更することにしました。書くのは楽しかったのですが、そもそも書くのにかかった時間よりも、それを読んだりデバッグしたりすることに多くの時間を費やしただけだと気づいたとき、信頼できます。
一方、DIMはばかげています:)
VB.NET はそのままでも優れており、コードがより明確になります。
たとえば、自分の結末をどのように説明できるかという事実が大好きです。
ながら終了 vs } 終了 for vs } 終了 if vs }
そして、実際には、インテリジェンスのために入力中の冗長性は問題になりません。
私はここで私の深さから少し外れています。
誰もが冗長と呼ぶものが好きです。自然言語 (英語など) に複数のネストされた括弧がないことを不思議に思う人はいませんか? 実際、ネストされた括弧は、読みやすくするためにインデントの規則が本当に必要です。自然言語では、冗長な句と複数の文を使用して、レイヤー化された括弧を回避するか、少なくとも説明します。
また、ある意味では、vb が c# よりもはるかに多くの構文を持っているとはまったく言えません。実際には、コードの特定のブロックに c# よりも多くの字句トークンが含まれているわけではありません (そうですか?)。構文は c# とほぼ同じですが、構文トークンが長くなります。たとえば、'}' ではなく 'End Sub' です。ほとんどの構文配管では、VB バージョンの方がタイピングが多くなります (インテリセンスを断念している場合)。また、'}' は 'End Sub' と比較してあいまいです。 . これは、ある意味でより簡潔になるわけではありません。コードには同じ数のトークンがまだありますが、より素っ気ないトークン マーカーのより小さなサブセットからのものです。しかし、C# の異なるトークンは、コンテキストに応じて異なる意味を持ちます。たとえば、コードブロックの最後がどこにある可能性があるとしても、場所を失った場合に読んでいるコードブロックの種類を取得するために、コードを読むときにネストされたレベルを念頭に置いておく必要があります。コード ブロックの先頭を確認するために検索する必要がある場合があります。これが当てはまらない場合でも、&& は AndAlso よりも本当に優れていますか?
Dimはまったく役に立たないと思います.c#と比較して余分な字句ですが、少なくともlinqと一致していると思います.vbはvarコマンドを必要としません. チョップの他の候補は考えられません。想像力がないのかもしれません。
誰かがやって来て、私がどれほど間違っているか教えてくれると確信しています:) とにかく、これは個人的な好みに関係していると思います。
次に、C# は ";" を取り除く必要があります。すべてのフリック行の終わりに:)
デフォルトは、「;」の代わりに「改行」などの簡単な方法である必要があります。同じ行に 2 つのステートメントなどの例外が必要な場合は、「:」や「;」などの区切り記号を使用する必要があります。
それが好きな人もいます。Dim のようなものは、他の何よりもレガシーな理由で残されているのではないかと思います。
ただし、VB には便利なショートカットがいくつかあります。たとえば、変換ルーチン。例:CInt、CStrなど
OK、私は C# 経由で .Net に来た古い C プログラマーです。今は VB.Net で作業しています。最初はその冗長さに愕然としましたが、少し C# に戻ったので、 VB.Net が少し好きになったことは認めざるを得ません。
私は、より読みやすく、より暗号化されていない VB コードを書くことができます (特に、すべての C# 中括弧を独自の行に配置する場合)。また、Visual Studio のエディターは、ほとんどの私にとっては冗長です。
私はどのようにDim X As List(Of SomeType)
読むのとは対照的に好きですList<sometype> X
セミコロンは今や迷惑です。中括弧は面倒です。
ただし、配列参照の角括弧が少し恋しいです。
C# はユーザー フレンドリな言語ではなく、VB.Net と同じタスクを実行するためにさらに多くのコード行を必要とします。with/end with などのオプションのパラメーターは、C# ではサポートされていません。db 接続でさえ、C# ではより多くのコードを必要とします。ただし、プログラミング中にヨーダのように話すことができるため、スターウォーズのファンは C# を気に入っています。
My $0.02: VB.Net のインテリセンス機能、ショートカット、論理的な読みやすさなどにより、VB.Net は優れた言語になっています。
私がVBについて気に入らないことの1つはこれです
print("ByVal sender as object, ByVal e as EventArgs");
対 C#
object sender, Eventargs e
プリプロセッサを使用してください...そして、他の誰かに読まれるという希望を失います(または、おそらく数年後にはあなた自身...)。
Lua は冗長であると不平を言う人々によく寄せられる回答に、私は答えます。CLR に限定したとしても、周りにはたくさんの言語があります。(自分が始めていないプロジェクトに取り組んでいるかもしれません)。
それは炎でも何でもない。言語が多いのには理由があります。非常に簡潔で数学表記に近いものが好きな人もいれば、(多かれ少なかれ)冗長で読みやすいと感じる人もいます。すべての好みに対応する言語があります。
はい、あなたの言いたいことはわかります。少し長くなる可能性があります。キーワードが多すぎて、その背後にあるロジックを理解するのが難しくなるため、読みにくくなりますが、好きな人もいます.
私は最近、自分のすべてのものを C# で書き始めたばかりですが、VB を切り取り、今から正しい C# と言ったので、もっと好きになったと言わなければなりません。
これを行うと、コードが読みにくくなるだけです。