例（ケースに注意してください）：

string s = "Hello world!";
String s = "Hello world!";

それぞれの使用に関するガイドラインは何ですか？そして、違いは何ですか？

stringは、C＃のエイリアスですSystem.String。
したがって、技術的には違いはありません。それはint 対 System.Int32です。

ガイドラインに関してstringは、オブジェクトを参照するときは常に使用することをお勧めします。

例えば

string place = "world";

同様Stringに、クラスを具体的に参照する必要がある場合は、一般的に使用することをお勧めします。

例えば

string greet = String.Format("Hello {0}!", place);

これは、Microsoftが例で使用する傾向があるスタイルです。

StyleCopがC＃固有のエイリアスの使用を強制するようになったため、この領域のガイダンスが変更された可能性があります。

完全を期すために、ここに関連情報の頭脳ダンプがあります...

他の人が指摘したようにstring、はのエイリアスですSystem.String。それらは同じコードにコンパイルされるため、実行時に違いはありません。これは、C＃のエイリアスの1つにすぎません。完全なリストは次のとおりです。

object:  System.Object
string:  System.String
bool:    System.Boolean
byte:    System.Byte
sbyte:   System.SByte
short:   System.Int16
ushort:  System.UInt16
int:     System.Int32
uint:    System.UInt32
long:    System.Int64
ulong:   System.UInt64
float:   System.Single
double:  System.Double
decimal: System.Decimal
char:    System.Char

stringおよびを除いてobject、エイリアスはすべて値の型に対するものです。decimal値型ですが、CLRのプリミティブ型ではありません。エイリアスを持たない唯一のプリミティブ型はSystem.IntPtrです。

仕様では、値タイプのエイリアスは「単純タイプ」と呼ばれています。リテラルは、すべての単純型の定数値に使用できます。他の値タイプには、使用可能なリテラル形式はありません。（これをVBと比較してくださいDateTime。VB はリテラルを許可し、エイリアスも持っています。）

エイリアスを使用しなければならない状況が1つあります。列挙型の基礎となる型を明示的に指定する場合です。例えば：

public enum Foo : UInt32 {} // Invalid
public enum Bar : uint   {} // Valid

コロンがなければならないの後の部分-それは仕様定義列挙型の宣言方法の問題だ一体型のの1つのトークンで生産、sbyte、byte、short、ushort、int、uint、long、ulong、charとは対照的に、... 型として生産たとえば、変数宣言で使用されます。他の違いを示すものではありません。

最後に、どちらを使用するかということになります。個人的には、実装にはエイリアスを使用しますが、APIにはCLRタイプを使用します。実装に関してどれを使用するかはそれほど重要ではありません。チーム間の一貫性は良好ですが、他の誰も気にしません。一方、APIで型を参照する場合は、言語に依存しない方法で参照することが本当に重要です。呼び出されたメソッドReadInt32は明確ですが、呼び出されたメソッドにReadIntは解釈が必要です。呼び出し元は、たとえばのintエイリアスを定義する言語を使用している可能性がありますInt16。.NETフレームワークの設計者は、このパターンに従っています。その良い例はBitConverter、クラスにBinaryReaderありConvertます。

StringはSystem.String.NET Frameworkタイプの略です。stringは、 C＃言語のエイリアスです System.String。どちらもSystem.StringIL（Intermediate Language）でコンパイルされているため、違いはありません。あなたが好きなものを選んでそれを使ってください。C＃でコーディングする場合はstring、C＃タイプのエイリアスであり、C＃プログラマーによく知られているので、私はそれを好みます。

（int、System.Int32）などについても同じことが言えます。

提供された型エイリアスをC＃で使用することについて私が今まで聞いた最良の答えは、Jeffrey Richterの著書CLR Via C＃にあります。彼の3つの理由は次のとおりです。

• 私は開発者の数は、使用するかどうかわからない、混乱して見てきた文字列または文字列を自分のコードに。C＃では、文字列（キーワード）はSystem.String（FCLタイプ）に正確にマッピングされるため、違いはなく、どちらも使用できます。
• C＃では、longはSystem.Int64にマップされますが、別のプログラミング言語では、longはInt16またはInt32にマップできます。実際、C ++ / CLIは実際にはInt32として長く扱います。ある言語でソースコードを読んでいる人が、別のプログラミング言語でのプログラミングに慣れていると、コードの意図を簡単に誤って解釈する可能性があります。実際、ほとんどの言語では、キーワードとして長く扱われることも、それを使用するコードをコンパイルすることもありません。
• FCLには、メソッド名の一部として型名を持つ多くのメソッドがあります。たとえば、BinaryReader型はReadBoolean、ReadInt32、ReadSingleなどのメソッドを提供し、System.Convert型はToBoolean、ToInt32、ToSingleなどのメソッドを提供します。次のコードを書くことは合法ですが、floatを含む行は非常に不自然に感じられ、行が正しいかどうかは明らかではありません。

BinaryReader br = new BinaryReader(...);
float val  = br.ReadSingle(); // OK, but feels unnatural
Single val = br.ReadSingle(); // OK and feels good

だからあなたはそれを持っています。これらはすべて本当に良い点だと思います。しかし、私は自分のコードでジェフリーのアドバイスを使用していることに気づきません。たぶん、C＃の世界に行き詰まっているかもしれませんが、コードをフレームワークコードのように見せようとしています。

string予約語ですがString、単なるクラス名です。つまり、stringそれ自体を変数名として使用することはできません。

なんらかの理由でstringという変数が必要な場合は、最初のコンパイルのみが表示されます。

StringBuilder String = new StringBuilder();  // compiles
StringBuilder string = new StringBuilder();  // doesn't compile 

文字列と呼ばれる変数名が本当に必要な場合は@、プレフィックスとして使用できます。

StringBuilder @string = new StringBuilder();

もう1つの重要な違い：Stack Overflowはそれらを異なる方法で強調表示します。

1つの違いがあります -あなたが使用することはできませんStringなしにusing System;事前に。

それは上記でカバーされました。ただし、stringリフレクションでは使用できません。使用する必要がありますString。

System.Stringは.NET文字列クラスです-C＃stringではのエイリアスですSystem.String-使用中は同じです。

ガイドラインについては、あまり行き詰まらず、好きなように使用します。人生にはもっと重要なものがあり、コードはいずれにしても同じです。

あなたが使用している整数のサイズを指定することが必要であるシステムを構築する自分自身を見つけるので、使用する傾向がある場合はInt16、Int32、UInt16、UInt32などそれは使用することがより自然に見えるかもしれないString-と異なる.NET言語間を動き回るとき、それは可能性があります物事をより理解しやすくします-そうでなければ私は文字列とintを使用します。

.NETフォーマットの理由から、（エイリアスではなく） 大文字のタイプを使用します。.NET型は他のオブジェクトタイプ（値タイプは、すべての後に、適切なオブジェクトである）と同じ着色されています。

条件と制御キーワード（のようなif、switchおよび、return）小文字と（デフォルトで）着色されたダークブルーです。そして、私はどちらかと言えば、使用方法と形式に不一致がありません。

検討してください：

String someString; 
string anotherString; 

stringとStringすべての方法で同じです（大文字の「S」を除く）。どちらの方法でも、パフォーマンスへの影響はありません。

string構文の強調表示のため、ほとんどのプロジェクトでは小文字が推奨されます

C＃は、CLRと共に使用される言語です。

string C＃の型です。

System.String CLRのタイプです。

C＃をCLRと共に使用すると、stringにマッピングされSystem.Stringます。

理論的には、Javaバイトコードを生成するC＃コンパイラを実装できます。このコンパイラーの賢明な実装は、Javaランタイムライブラリと相互運用するためにおそらくマップstringさjava.lang.Stringれます。

このYouTubeビデオは、実際の違いを示しています。

しかし、今は長いテキストの答えです。

我々はについて話すとき.NET二つの異なるものがあるものがある.NETフレームワークや他の言語（存在しC#、VB.NETそのフレームワークを使用するなど）。

" System.String" aka "String"（大文字の "S"）は.NETフレームワークのデータ型であり、 "string"はC#データ型です。

簡単に言うと、「文字列」は「文字列」のエイリアス（同じものを別の名前で呼びます）です。したがって、技術的には以下の両方のコードステートメントは同じ出力を提供します。

String s = "I am String";

または

string s = "I am String";

同様に、以下に示すように、他のc＃データ型のエイリアスがあります。

オブジェクト：System.Object、文字列：System.String、ブール：System.Boolean、バイト：System.Byte、s バイト：System.SByte、ショート：System.Int16など

プログラマーの観点から見た100万ドルの質問では、「文字列」と「文字列」をいつ使用するのでしょうか。

混乱を避けるために、最初に一貫してそれらの1つを使用してください。ただし、ベストプラクティスの観点から、変数宣言を行う場合は「文字列」（小さな「s」）を使用するのが適切であり、クラス名として使用する場合は「文字列」（大文字の「S」）が推奨されます。

以下のコードでは、左側が変数宣言であり、「string」を使用して宣言されています。右側ではメソッドを呼び出しているので、 "String"の方が賢明です。

string s = String.ToUpper() ;

小文字stringはのエイリアスですSystem.String。それらはでも同じですC#。

あなたはシステムの種類（使用する必要があるかどうかをめぐる議論がありますSystem.Int32、System.Stringなど）タイプまたはC# aliases（int、stringなど）。私はあなたがを使うべきだと個人的に信じていますがC# aliases、それは私の個人的な好みにすぎません。

stringは単なるのエイリアスですSystem.String。コンパイラはそれらを同じように扱います。

唯一の実用的な違いは、あなたが言及するように構文の強調表示であり、using Systemそれを使用する場合は記述する必要があることStringです。

どちらも同じです。ただし、コーディングガイドラインの観点からは、のstring代わりに使用することをお勧めしますString。これは一般的に開発者が使用するものです。代わりに使用するなどInt32、私たちが使うはintようintにエイリアスですInt32

FYI「キーワード文字列は、事前定義されたクラスの単なるエイリアスですSystem.String。」-C＃言語仕様4.2.3 http://msdn2.microsoft.com/En-US/library/aa691153.aspx

他の人が言っているように、彼らは同じです。StyleCopルールは、デフォルトでは、あなたが使用することを強制されますstringC＃コードのスタイルとして参照する場合を除き、ベストプラクティス、System.Stringのような静的関数、String.Format、String.Join、String.Concat、など...

6年5カ月後の新しい答え（去勢）。

一方でstring、常に一定の意味を持つ予約済みのC＃のキーワードで、String普通である識別子ものを参照することができます。現在のタイプのメンバーに応じて、現在の名前空間と適用されるusingディレクティブおよびそれらの配置は、とStringは異なる値またはタイプになる可能性がありますglobal::System.String。

usingディレクティブが役に立たない 2つの例を示します。

まず、Stringある値、電流型（またはローカル変数）のは：

class MySequence<TElement>
{
  public IEnumerable<TElement> String { get; set; }

  void Example()
  {
    var test = String.Format("Hello {0}.", DateTime.Today.DayOfWeek);
  }
}

にIEnumerable<>はと呼ばれる非静的メンバーがFormatなく、拡張メソッドが適用されないため、上記はコンパイルされません。上記の場合、型が構文的に唯一の可能性Stringである他のコンテキストで使用することはまだ可能です。たとえば、名前空間とディレクティブに応じてOKにすることができます。String local = "Hi mum!";using

さらに悪いことに：String.Concat(someSequence)（usings によっては）Linq拡張メソッドに行く可能性が高いEnumerable.Concatです。静的メソッドには行きませんstring.Concat。

次に、Stringが別のタイプである場合、現在のタイプ内にネストされます。

class MyPiano
{
  protected class String
  {
  }

  void Example()
  {
    var test1 = String.Format("Hello {0}.", DateTime.Today.DayOfWeek);
    String test2 = "Goodbye";
  }
}

Exampleメソッドのどちらのステートメントもコンパイルされません。ここにStringは常にピアノの弦がありMyPiano.Stringます。メンバーが存在しstaticない（またはFormat存在しない）（またはその基本クラスから継承されている）。そして、値"Goodbye"をそれに変換することはできません。

システムタイプを使用すると、C＃とVB.Netの間での移植が容易になります。

Jon Skeetが述べたように、他のプログラマーの間で一般的な慣習のように思われるものに対して、私は参照タイプであるという事実を強調するためだけに優先Stringします。stringString

stringのエイリアス（または省略表現）ですSystem.String。つまり、入力するとstringはを意味することになりSystem.Stringます。think linkで詳細を読むことができます：'string'はSystem.Stringのエイリアス/省略形です。

Ritchersの本から、これをlfoustsの回答に追加したいと思います。

C＃言語仕様には、「スタイルの問題として、完全なシステムタイプ名を使用するよりもキーワードを使用する方が好ましい」と記載されています。言語仕様に同意しません。私はFCLタイプ名を使用し、プリミティブタイプ名を完全に回避することを好みます。実際、コンパイラーがプリミティブ型名さえ提供せず、開発者に代わりにFCL型名を使用するように強制したいのですが。ここに私の理由があります：

• 私は開発者の数は、使用するかどうかわからない、混乱して見てきた文字列 または文字列を自分のコードに。C＃では、文字列（キーワード）はSystem.String（FCLタイプ）に正確にマップ されるため、違いはなく、どちらも使用できます。同様に、アプリケーションが32ビットOSで実行されている場合はintが32ビット整数を表し、アプリケーションが64ビットOSで実行されている場合は64ビット整数を表すと開発者が言う開発者もいます。このステートメントは完全に偽です。C＃では、intは常にSystem.Int32にマップされるため、コードが実行されているOSに関係なく、32ビット整数を表します。プログラマーが使用する場合Int32のコードでは、この潜在的な混乱も解消されます。

• C＃では、longはSystem.Int64にマップされますが、別のプログラミング言語では、long はInt16またはInt32にマップできます。実際、C ++ / CLIはInt32として長く扱います。ある言語でソースコードを読んでいる誰かが、別のプログラミング言語でのプログラミングに慣れていると、コードの意図を簡単に誤解する可能性があります。実際、ほとんどの言語では、キーワードとして長く扱われることも、それを使用するコードをコンパイルすることもありません。

• FCLには、メソッド名の一部として型名を持つ多くのメソッドがあります。たとえば、BinaryReader型はReadBoolean、ReadInt32、 ReadSingleなどのメソッドを提供し、System.Convert型はToBoolean、ToInt32、ToSingleなどのメソッドを提供します 。次のコードを書くことは合法ですが、floatを含む行は非常に不自然に感じられ、行が正しいかどうかは明らかではありません。

  BinaryReader br = new BinaryReader(...);
  float val = br.ReadSingle(); // OK, but feels unnatural
  Single val = br.ReadSingle(); // OK and feels good

• C＃を排他的に使用する多くのプログラマーは、他のプログラミング言語をCLRに対して使用できることを忘れがちです。そのため、C＃の機能はクラスライブラリコードに侵入します。たとえば、MicrosoftのFCLは、ほぼ独占的にFCLチームにC＃や開発者に書かれている、今のようなライブラリにする方法を導入している アレイのGetLongLength返し、Int64のある値の長い C＃ではなく、Cのような他の言語（中に++ / CLI）。別の例は、System.Linq.Enumerableの LongCountメソッドです。

完全なパラグラフを読む前に彼の意見を聞きませんでした。

文字列（System.String）は、基本クラスライブラリのクラスです。文字列（小文字）はC＃で予約されている作業で、System.Stringのエイリアスです。Int32とintは同じような状況ですBoolean vs. bool。これらのC＃言語固有のキーワードを使用すると、Cと同様のスタイルでプリミティブを宣言できます。

Stringはキーワードではないため、識別子として使用できますstringが、はキーワードであり、識別子としては使用できません。そして、機能の観点では、両方とも同じです。

本当に、それは慣習の問題です。 stringC / C ++スタイルに似ています。一般的な規則では、選択した言語で提供されているショートカットを使用します（int / Int for Int32）。これは「オブジェクト」にdecimalも当てはまります。

理論的にはこれは「INT」に意味するかもしれないいくつかの将来の64ビット標準にポートコードに役立つかもしれないInt64が、それはポイントではない、と私はすべてのアップグレードウィザードが任意の変更を期待するintへの参照Int32安全のためにとにかくだけを。

パーティーに遅刻：私はCLRタイプを100％使用します（まあ、C＃タイプを使用するよう強制された場合を除いて、最後にいつだったか覚えていません）。

リッチーのCLRの本のように、私はもともとこの数年前に始めました。すべてのCLR言語が最終的にCLR型のセットをサポートできる必要があるため、自分でCLR型を使用すると、より明確で、場合によってはより「再利用可能な」コードが提供されることがわかりました。

私は何年もそれをやってきたので、それは習慣です、そして私はVSがCLRタイプに示す色付けが好きです。

実際の唯一の問題は、オートコンプリートがC＃タイプを使用することです。そのため、自動生成されたタイプを再入力して、代わりにCLRタイプを指定します。

また、「int」または「string」が表示されると、1970年代のCコードを見るように、本当に間違っているように見えます。

違いはありません。

C＃キーワードstringは.NETタイプにマップされますSystem.String-これは、言語の命名規則に準拠するエイリアスです。

同様に、にintマッピングされSystem.Int32ます。

ダニエル・ソリスの本からこの問題についての引用があります。

事前定義されたタイプはすべて、基礎となる.NETタイプに直接マップされます。C＃タイプ名（文字列）は.NETタイプ（文字列またはSystem.String）の単なるエイリアスであるため、.NET名を使用すると構文的に問題なく動作しますが、これはお勧めできません。C＃プログラム内では、.NET名ではなくC＃名を使用する必要があります。

stringはキーワードであり、stringを識別子として使用することはできません。

文字列はキーワードではないため、識別子として使用できます。

例

string String = "I am a string";

キーワードstring は、System.Stringキーワードの問題以外のエイリアスです 。この2つはまったく同じです。

 typeof(string) == typeof(String) == typeof(System.String)

はい、それはboolとのように、それらの間に違いはありませんBoolean。

@JaredPar（C＃コンパイラの開発者であり、多作なSOユーザーです！）が、この問題について素晴らしいブログ投稿を書いています。ここで共有する価値があると思います。それは私たちのテーマについての良い見方です。

string対Stringはスタイルの議論ではありません

[...]

キーワードstringはC＃では具体的な意味を持っています。System.Stringコアランタイムアセンブリに存在するタイプです。ランタイムは本質的にこのタイプを理解し、開発者が.NETの文字列に期待する機能を提供します。その存在はC＃にとって非常に重要であり、その型が存在しない場合、コンパイラーはコード行の解析さえ試みる前に終了します。したがってstring、C＃コードでは正確で明確な意味があります。

Stringただし、C＃では識別子は具体的な意味を持ちません。それはように、すべての名前のルックアップのルールを通過する識別子でありWidget、Studentそれは文字列に結合することができるか、それが別のアセンブリ完全にその目的とは全く異なるかもしれタイプに特異的に結合することができ、等... string。さらに悪いことに、次のようなコードで定義できますString s = "hello"。コンパイルし続けました。

class TricksterString { 
  void Example() {
    String s = "Hello World"; // Okay but probably not what you expect.
  }
}

class String {
  public static implicit operator String(string s) => null;
}

の実際の意味は、String常に名前解決に依存します。つまり、プロジェクト内のすべてのソースファイルと、参照されるすべてのアセンブリで定義されているすべてのタイプに依存します。要するに、それが何を意味するのかを知るにはかなりのコンテキストが必要です。

真の例大多数であることStringとstring同じタイプにバインドします。しかし、Stringまだ使用するということは、開発者が正しい答えが1つしかない場所でプログラムを解釈に任せることを意味します。場合はString、間違った型に結合しないことは、コンパイラチームにバグを提出し、一般的に使用して保存されていたかもしれない時間を無駄、時間のデバッグ開発者を残すことができますstring。

違いを視覚化する別の方法は、このサンプルを使用することです。

string s1 = 42; // Errors 100% of the time  
String s2 = 42; // Might error, might not, depends on the code

多くの人は、これは情報Stringですが、コードベースがこの名前のタイプを定義することは非常にまれであるため、技術的に正確な使用でも問題ないと主張します。または、Stringそれが定義されている場合、それは悪いコードベースの兆候です。

[...]

あなたはそれが表示されますStringこれらのライブラリのいずれかのために...など反射ヘルパー、シリアライズライブラリ、レクサー、プロトコル、：完全に有効ないくつかの目的のために定義されたString対stringのコードが使用されている場所に応じて、実際の結果があります。

ですから、Stringvs。のstring議論を見るとき、これはスタイルではなく、意味論についてです。文字列を選択すると、コードベースに明確な意味が与えられます。選択Stringは間違いではありませんが、将来の驚きに備えてドアを開いたままにしています。

注：アーカイブのため、ほとんどのブログ投稿をコピー/貼り付けました。一部を無視しているので、できればスキップしてブログ記事を読むことをお勧めします。