2

言語のキーワードが完全な型名 ( 、 など) に置き換えられているソース コードをよく System.String見かけSystem.Int32ますSystem.GUID。

さらに、これを行う人はどこでも完全な型名を書き、ソースをそのような宣言でいっぱいにします:

System.Collections.Generic.List<System.Reflection.PropertyInfo> list = System.Collections.Generic.List<System.Reflection.PropertyInfo>(newSystem.Reflection.PropertyInfo[] { ... });

なぜこれを行うのかと尋ねると、「型名の衝突を避けるのに役立つ」、「よりプロフェッショナルに見える」、「私のVSプラグインが自動的にやってくれる」など、幅広い答えが返ってきます。

usingソースコードファイル全体で型を1回使用する場合、完全な型名を書くと不要な記述を避けることができる場合があることは理解しています。また、タイプを明示的に宣言する必要がある場合もあります。良い例は ThreadingTimerと WinFormsTimerです。

しかし、DB 呼び出しを大量にソースSystem.Data.SqlClient.SqlCommandし、'SqlCommand' の代わりに書くと、私にはかなり奇妙に見えます。

どう思いますか？私は正しいですか、それとも何かを理解していませんか?

ありがとうございました！

PSそして別の現象は、if (0 != variable代わりに）を書いていif (variable != 0)ます。

4

7 に答える 7

6

問題はif (0 == variable)、誤って を書き込むことを防ぐために使用される C++ の規則if (variable = 0)です。これは C++ では有効ですが、意図したとおりに動作しません。間違ったバージョンはコンパイルされないため、C# では完全に不要です。そのため、代わりに別のバージョンを使用する必要があります。

個人的には、できるだけ書くことを避けたいので、名前空間の衝突がない限り、完全に限定することはありません。

stringvsについては、完全なクラス名ではなくエイリアス ( / )Stringを常に使用しますが、これは純粋に慣例であり、実行時の違いはありません。stringint

于 2010-10-01T09:59:29.423 に答える
2

率直に言って、私には反対に見えるので、「よりプロフェッショナルに見える」ことに強く反対します。

つまり、ソース ファイル全体で名前空間の 1 つのメンバーを使用する場合は、using.

優先などには、等号0 != xのx != 0オーバーライドやその他のいくつかの点に応じて、いくつかの利点があります。これは、他のいくつかの言語ではより一般的であるため、二日酔いになる可能性があります。null を最初に配置することを好む人が特によく見られます。これは、null を等価オーバーライドに渡す可能性が低くなるためです (これも、他の言語ではより一般的な問題です)。タイプミスによる偶発的な代入を回避することもできますが、C# ではこれが問題になることはめったにありません (使用している型が bool でない限り)。

于 2010-10-01T10:25:07.430 に答える
1

少し主観的ですが、コーディング標準で別段の定めがない限り、名前空間を削除する方が冗長性が低く、読みやすくなるため、常に良いと思います。名前空間の競合がある場合は、何かを意味する短いエイリアスを使用してください。

最後のポイントについては、name.Equals("Paul") と "Paul".Equals(name) を比較すると、name が null でない限り、どちらも同じことを行います。この場合、1 つ目は null 例外で失敗し、2 つ目 (正しくは?) は false を返します。

于 2010-10-01T10:02:29.963 に答える
1

プリミティブ データ型の場合: ここで質問が重複しています - C#、int、または Int32? 気にする必要がありますか？

非プリミティブ データ型の場合: 与えられた回答は有効です。特に、「型名の衝突を回避するのに役立ちます」

: 変数はif (0 != variable)式で比較する対象なので、最初に移動する必要があります。だから、私は好むだろうif (variable != 0).

于 2010-10-01T10:04:07.717 に答える
1

これらの理由には説得力があるとは思えません。usingステートメントを追加する方が良いです。

2 つの小さな例外:

  • 生成されたコードでは、冗長な名前空間プレフィックスが表示される場合がありますが、このコードは編集用にインデントされていないため問題ありません。
  • Int32タイプが正確に 32 ビットであることに依存する場合、明示的に記述すると役立つ場合があります。
于 2010-10-01T10:06:05.777 に答える
1

できるだけ読みやすいコードにしましょう！参照: http://en.wikipedia.org/wiki/KISS_principle

「プロフェッショナルに見える」というのは非常に悪い議論です。

ところで、コードが SQL ステートメントでいっぱいの場合は、とにかくそれをリファクタリングすることをお勧めします。

于 2010-10-01T10:15:04.180 に答える
1

文字列と文字列について。stringその場合、つまり、他のプログラミング言語と同様に文字列を使用しようとします。しかし、それがオブジェクトの場合 (または String クラスを参照している場合)、私は を使用しようとしますString。

于 2010-10-01T10:22:19.107 に答える