Exemplo ( observe o caso ):

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

Quais são as diretrizes para o uso de cada um? E quais são as diferenças?

stringé um alias em C # para System.String.
Então, tecnicamente, não há diferença. É como int vs. System.Int32 .

No que diz respeito às diretrizes, geralmente é recomendável usar stringsempre que você estiver se referindo a um objeto.

por exemplo

string place = "world";

Da mesma forma, acho que geralmente é recomendável usar Stringse você precisar se referir especificamente à turma.

por exemplo

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

Esse é o estilo que a Microsoft costuma usar em seus exemplos .

Parece que as orientações nesta área podem ter sido alteradas, já que o StyleCop agora impõe o uso de aliases específicos de C #.

Apenas por uma questão de integridade, aqui está um despejo cerebral de informações relacionadas ...

Como outros observaram, stringé um apelido para System.String. Eles são compilados com o mesmo código, portanto, no tempo de execução, não há diferença alguma. Este é apenas um dos aliases em C #. A lista completa é:

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

Além de stringe object, os alias são todos para tipos de valor. decimalé um tipo de valor, mas não um tipo primitivo no CLR. O único tipo primitivo que não possui um alias é System.IntPtr.

Na especificação, os aliases de tipo de valor são conhecidos como "tipos simples". Os literais podem ser usados ​​para valores constantes de todos os tipos simples; nenhum outro tipo de valor tem formas literais disponíveis. (Compare isso com o VB, que permite DateTimeliterais e também possui um alias.)

Há uma circunstância em que você precisa usar os aliases: ao especificar explicitamente o tipo subjacente de uma enumeração. Por exemplo:

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

Isso é apenas uma questão de como a especificação define enum declarações - a parte após os dois pontos tem que ser o tipo integrante de produção, que é um símbolo de sbyte, byte, short, ushort, int, uint, long, ulong, char... em oposição a um tipo de produção como usado por declarações variáveis, por exemplo. Não indica nenhuma outra diferença.

Finalmente, quando se trata de usar: pessoalmente, uso os aliases em todos os lugares para a implementação, mas o tipo CLR para qualquer API. Realmente não importa muito o que você usa em termos de implementação - a consistência entre sua equipe é boa, mas ninguém mais vai se importar. Por outro lado, é realmente importante que, se você se referir a um tipo em uma API, faça isso de maneira neutra em termos de idioma. Um método chamado ReadInt32é inequívoco, enquanto um método chamado ReadIntrequer interpretação. O chamador pode estar usando um idioma que define um intalias para Int16, por exemplo. Os designers .NET framework seguiram esse padrão, bons exemplos sendo nos BitConverter, BinaryReadere Convertclasses.

Stringsignifica System.Stringe é do tipo .NET Framework. stringé um alias na linguagem C # para System.String. Ambos são compilados System.Stringem IL (Intermediate Language), portanto não há diferença. Escolha o que você gosta e use isso. Se você codificar em C #, eu prefiro string, pois é um alias do tipo C # e conhecido pelos programadores de C #.

Eu posso dizer o mesmo sobre ( int, System.Int32) etc.

A melhor resposta que já ouvi sobre o uso dos aliases de tipo fornecidos em C # vem de Jeffrey Richter em seu livro CLR Via C # . Aqui estão suas três razões:

• Eu já vi vários desenvolvedores confusos, sem saber se deveriam usar string ou String em seu código. Como no C # a cadeia de caracteres (uma palavra-chave) é mapeada exatamente para System.String (um tipo de FCL), não há diferença e pode ser usada.
• Em C #, mapas longos para System.Int64 , mas em uma linguagem de programação diferente, longos podem ser mapeados para um Int16 ou Int32 . De fato, o C ++ / CLI realmente trata por muito tempo como um Int32 . Alguém que lê o código fonte em um idioma pode facilmente interpretar mal a intenção do código se ele ou ela estiver acostumado a programar em uma linguagem de programação diferente. Na verdade, a maioria das línguas não vai mesmo tratar longa como uma palavra-chave e não vai código de compilação que o utiliza.
• O FCL tem muitos métodos que possuem nomes de tipo como parte de seus nomes de método. Por exemplo, o tipo BinaryReader oferece métodos como ReadBoolean , ReadInt32 , ReadSingle e assim por diante, e o tipo System.Convert oferece métodos como ToBoolean , ToInt32 , ToSingle e assim por diante. Embora seja legal escrever o código a seguir, a linha com float parece muito natural para mim e não é óbvio que a linha esteja correta:

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

Então aí está. Eu acho que esses são realmente bons pontos. No entanto, não me vejo usando os conselhos de Jeffrey em meu próprio código. Talvez eu esteja muito preso no meu mundo C #, mas acabe tentando fazer meu código parecer com o código da estrutura.

stringé uma palavra reservada, mas Stringé apenas um nome de classe. Isso significa que stringnão pode ser usado como um nome de variável por si só.

Se, por algum motivo, você quiser uma variável chamada string , verá apenas a primeira dessas compilações:

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

Se você realmente deseja um nome de variável chamado string, pode usar @como prefixo:

StringBuilder @string = new StringBuilder();

Outra diferença crítica: o Stack Overflow os destaca de maneira diferente.

Há uma diferença - você não pode usar Stringsem using System;antes.

Foi coberto acima; no entanto, você não pode usar stringna reflexão; você deve usar String.

System.Stringé a classe de seqüência de caracteres .NET - em C # stringé um alias para System.String-, portanto, em uso elas são as mesmas.

Quanto às diretrizes, eu não ficaria muito atolado e usaria o que quisesse - há coisas mais importantes na vida e o código continuará o mesmo.

Se você encontrar-se a construção de sistemas onde é necessário especificar o tamanho dos inteiros que você está usando e assim tendem a usar Int16, Int32, UInt16, UInt32etc., então pode parecer mais natural para usar String- e quando se deslocam entre diferentes linguagens .NET que poderia tornar as coisas mais compreensíveis - caso contrário, eu usaria string e int.

Prefiro os .NETtipos de letra maiúscula (em vez dos aliases) por motivos de formatação. Os .NETtipos são coloridos da mesma forma que outros tipos de objetos (afinal, os tipos de valor são objetos adequados).

As palavras-chave condicionais e de controle (como if, switche return) são minúsculas e coloridas em azul escuro (por padrão). E eu preferiria não ter discordância quanto ao uso e formato.

Considerar:

String someString; 
string anotherString; 

stringe Stringsão idênticos em todos os aspectos (exceto em maiúsculas "S"). Não há implicações de desempenho de qualquer maneira.

Letras minúsculas stringsão preferidas na maioria dos projetos devido ao realce da sintaxe

C # é um idioma usado junto com o CLR.

string é um tipo em c #.

System.String é um tipo no CLR.

Quando você usa C # junto com o CLR string, é mapeado para System.String.

Teoricamente, você poderia implementar um compilador C # que gerasse o bytecode Java. A aplicação sensata deste compilador provavelmente mapear stringa java.lang.Stringfim de interoperar com a biblioteca de tempo de execução Java.

Este vídeo do YouTube demonstra praticamente como eles diferem.

Mas agora, para uma longa resposta textual.

Quando falamos sobre, .NETexistem duas coisas diferentes, uma existe .NETframework e a outra há linguagens ( C#, VB.NETetc) que usam essa estrutura.

" System.String" aka "String" (capital "S") é um .NETtipo de dados da estrutura, enquanto "string" é um C#tipo de dados.

Em resumo, "String" é um alias (a mesma coisa chamada com nomes diferentes) de "string". Portanto, tecnicamente, as duas instruções de código abaixo fornecerão a mesma saída.

String s = "I am String";

ou

string s = "I am String";

Da mesma maneira, existem aliases para outro tipo de dados c #, como mostrado abaixo: -

objeto: System.Object, string: System.String, bool: System.Boolean, byte: System.Byte, sbyte: System.SByte, resumo: System.Int16e assim por diante

Agora, a pergunta de um milhão de dólares do ponto de vista do programador Então, quando usar "String" e "string"?

A primeira coisa a evitar confusão é usar um deles de forma consistente. Mas, da perspectiva das melhores práticas, quando você faz uma declaração variável, é bom usar "string" (pequeno "s") e, quando você o usa como nome de classe, é preferível "String" (capital "S").

No código abaixo, o lado esquerdo é uma declaração de variável e declarada usando "string". No lado direito, estamos chamando um método para que "String" seja mais sensato.

string s = String.ToUpper() ;

Minúsculas stringé um alias para System.String. Eles são os mesmos C#.

Há um debate sobre se você deve usar os tipos de sistema ( System.Int32, System.String, etc.) Tipos ou o C# aliases( int, string, etc). Pessoalmente, acredito que você deve usar o C# aliases, mas essa é apenas a minha preferência pessoal.

stringé apenas um apelido para System.String. O compilador irá tratá-los de forma idêntica.

A única diferença prática é o destaque da sintaxe, como você menciona, e que você deve escrever using Systemse usar String.

Ambos são iguais. Mas a partir de diretrizes de codificação perspectiva, é melhor usar stringem vez de String. Isso é o que geralmente os desenvolvedores usam. por exemplo, em vez de usar Int32usamos intcomo inté alias paraInt32

FYI "A palavra-chave string é simplesmente um alias para a classe predefinida System.String." - Especificação da linguagem C # 4.2.3 http://msdn2.microsoft.com/En-US/library/aa691153.aspx

Como os outros estão dizendo, eles são os mesmos. Regras StyleCop, por padrão, irá impor-lhe utilizar stringcomo um estilo de código C # melhor prática, exceto ao fazer referência a System.Stringfunções estáticas, tais como String.Format, String.Join, String.Concat, etc ...

Nova resposta após 6 anos e 5 meses (procrastinação).

Embora stringseja uma palavra-chave C # reservada que sempre tenha um significado fixo, Stringé apenas um identificador comum que pode se referir a qualquer coisa. Dependendo dos membros do tipo atual, o espaço para nome atual e as usingdiretivas aplicadas e seu posicionamento Stringpodem ser um valor ou um tipo diferente global::System.String.

Darei dois exemplos em que as usingdiretivas não ajudarão .

Primeiro, quando Stringé um valor do tipo atual (ou uma variável local):

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

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

O acima não será compilado porque IEnumerable<> não possui um membro não estático chamado Formate nenhum método de extensão se aplica. No caso acima, ainda pode ser possível usar Stringem outros contextos em que um tipo é a única possibilidade sintaticamente. Por exemplo, String local = "Hi mum!";pode ser bom (dependendo do espaço para nome eusing diretivas).

Pior: dizendo String.Concat(someSequence) é provável que o ditado (dependendo de using) vá para o método de extensão Linq Enumerable.Concat. Não irá para o método estático string.Concat.

Em segundo lugar, quando String é outro tipo , aninhado dentro do tipo atual:

class MyPiano
{
  protected class String
  {
  }

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

Nenhuma instrução no Examplemétodo é compilada. Aqui Stringé sempre um piano corda , MyPiano.String. Nenhum membro ( staticou não) Formatexiste nele (ou é herdado de sua classe base). E o valor"Goodbye" não pode ser convertido nele.

O uso de tipos de sistema facilita a porta entre C # e VB.Net, se você gosta desse tipo de coisa.

Contra o que parece ser prática comum entre os outros programadores, eu prefiro Stringmais string, apenas para destacar o fato de que Stringé um tipo de referência, como Jon Skeet mencionado.

stringé um apelido (ou taquigrafia) de System.String. Isso significa que, digitando, stringqueremos dizer System.String. Você pode ler mais no link think: 'string' é um apelido / abreviação de System.String.

Gostaria apenas de acrescentar isso à resposta da esquerda, do livro de Ritchers:

A especificação da linguagem C # declara: "Por uma questão de estilo, o uso da palavra-chave é favorecido sobre o uso do nome completo do tipo de sistema". Eu discordo da especificação de idioma; Prefiro usar os nomes de tipos FCL e evitar completamente os nomes de tipos primitivos. Na verdade, eu gostaria que os compiladores nem sequer oferecessem os nomes dos tipos primitivos e forçassem os desenvolvedores a usar os nomes dos tipos FCL. Aqui estão as minhas razões:

• Eu já vi vários desenvolvedores confusos, sem saber se deveriam usar string ou String em seu código. Como na string C # (uma palavra-chave) mapeia exatamente para System.String (um tipo FCL), não há diferença e pode ser usada. Da mesma forma, ouvi alguns desenvolvedores dizerem que int representa um número inteiro de 32 bits quando o aplicativo está sendo executado em um sistema operacional de 32 bits e que representa um número inteiro de 64 bits quando o aplicativo está sendo executado em um sistema operacional de 64 bits. Essa declaração é absolutamente falsa: em C #, um int sempre mapeia para Int32 em seu código, então essa confusão em potencial também é eliminada. System.Int32 e, portanto, representa um número inteiro de 32 bits, independentemente do SO em que o código está sendo executado. Se os programadores usassem

• Em C #, mapas longos para System.Int64 , mas em uma linguagem de programação diferente, longos podem ser mapeados para um Int16 ou Int32 . De fato, o C ++ / CLI trata por muito tempo como um Int32 . Alguém que lê o código fonte em um idioma pode facilmente interpretar mal a intenção do código se ele ou ela estiver acostumado a programar em uma linguagem de programação diferente. Na verdade, a maioria das línguas não vai mesmo tratar longa como uma palavra-chave e não vai código de compilação que o utiliza.

• O FCL tem muitos métodos que possuem nomes de tipo como parte de seus nomes de método. Por exemplo, o tipo BinaryReader oferece métodos como ReadBoolean , ReadInt32 , ReadSingle e assim por diante, e o tipo System.Convert oferece métodos como ToBoolean , ToInt32 , ToSingle e assim por diante. Embora seja legal escrever o código a seguir, a linha com float parece muito natural para mim e não é óbvio que a linha esteja correta:

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

• Muitos programadores que usam C # exclusivamente tendem a esquecer que outras linguagens de programação podem ser usadas no CLR e, por causa disso, os organismos C # se infiltram no código da biblioteca de classes. Por exemplo, FCL da Microsoft é quase exclusivamente escrito em C # e desenvolvedores na equipe FCL já introduziu métodos para a biblioteca como matriz ‘s GetLongLength , que retorna um Int64 valor que é um longa em C #, mas não em outros idiomas (como C ++ / CLI). Outro exemplo é o método LongCount de System.Linq.Enumerable .

Não recebi a opinião dele antes de ler o parágrafo completo.

String ( System.String) é uma classe na biblioteca de classes base. string (minúscula) é um trabalho reservado em C # que é um alias para System.String. Int32 vs int é uma situação semelhante à atual Boolean vs. bool. Essas palavras-chave específicas do idioma C # permitem declarar primitivas em um estilo semelhante a C.

Stringnão é uma palavra-chave e pode ser usada como identificador, enquanto stringé uma palavra-chave e não pode ser usada como identificador. E no ponto de vista da função, ambos são iguais.

É uma questão de convenção, realmente. stringapenas se parece mais com o estilo C / C ++. A convenção geral é usar os atalhos fornecidos pelo idioma escolhido (int / Int for Int32). Isso vale para "objeto" e decimaltambém.

Teoricamente, isso poderia ajudar a transportar o código para algum padrão futuro de 64 bits no qual "int" possa significar Int64, mas esse não é o ponto, e eu esperaria que qualquer assistente de atualização alterasse as intreferências de Int32qualquer maneira apenas por segurança.

Chegando atrasado à festa: eu uso os tipos CLR 100% do tempo (bem, exceto se forçado a usar o tipo C #, mas não me lembro quando foi a última vez).

Eu originalmente comecei a fazer isso anos atrás, de acordo com os livros de Ritchie sobre CLR. Fazia sentido para mim que todas as linguagens CLR finalmente deveriam ser capazes de suportar o conjunto de tipos CLR, portanto, o uso dos tipos CLR forneceu um código mais claro e possivelmente mais "reutilizável".

Agora que faço isso há anos, é um hábito e gosto da cor que o VS mostra para os tipos de CLR.

A única desvantagem real é que o preenchimento automático usa o tipo C #, então acabo digitando novamente os tipos gerados automaticamente para especificar o tipo CLR.

Além disso, agora, quando vejo "int" ou "string", parece realmente errado para mim, como se estivesse vendo o código C dos anos 70.

Não há diferença.

A palavra-chave C # é stringmapeada para o tipo .NET System.String- é um alias que mantém as convenções de nomenclatura do idioma.

Da mesma forma, intmapeia para System.Int32.

Há uma citação sobre esse assunto no livro de Daniel Solis .

Todos os tipos predefinidos são mapeados diretamente para os tipos .NET subjacentes. Os nomes de tipo C # (string) são simplesmente aliases para os tipos .NET (String ou System.String), portanto, o uso dos nomes .NET funciona bem sintaticamente, embora isso não seja recomendável. Dentro de um programa C #, você deve usar os nomes C # em vez dos nomes .NET.

string é uma palavra-chave e você não pode usar string como um identificador.

String não é uma palavra-chave e você pode usá-lo como um identificador:

Exemplo

string String = "I am a string";

A palavra string - chave é um alias, System.Stringalém do problema da palavra-chave, os dois são exatamente equivalentes.

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

Sim, não há diferença entre eles, assim como o boole Boolean.

O @JaredPar (desenvolvedor do compilador C # e prolífico usuário de SO!) Escreveu um ótimo post sobre esse assunto. Eu acho que vale a pena compartilhar aqui. É uma boa perspectiva sobre o assunto.

stringvs. Stringnão é um debate de estilo

[...]

A palavra string- chave tem um significado concreto em C #. É o tipo System.Stringque existe no assembly de tempo de execução principal. O tempo de execução compreende intrinsecamente esse tipo e fornece os recursos que os desenvolvedores esperam para cadeias de caracteres no .NET. Sua presença é tão crítica para o C # que, se esse tipo não existir, o compilador será encerrado antes de tentar analisar uma linha de código. Portanto, stringtem um significado preciso e inequívoco no código C #.

O identificador, Stringporém, não tem significado concreto em C #. É um identificador que passa por todas as regras de pesquisa de nomes como Widget, Studentetc ... Poderia ligar-se a uma string ou a um tipo em outro assembly inteiramente cujas finalidades podem ser totalmente diferentes string. Pior ainda, poderia ser definido de uma maneira que o código goste String s = "hello"; continuou a compilar.

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;
}

O significado real de Stringsempre dependerá da resolução do nome. Isso significa que depende de todos os arquivos de origem no projeto e de todos os tipos definidos em todos os assemblies referenciados. Em suma, é necessário um pouco de contexto para saber o que isso significa.

É verdade que na grande maioria dos casos Stringe stringse ligará ao mesmo tipo. Mas usar Stringainda significa que os desenvolvedores estão deixando seu programa para interpretação em locais onde há apenas uma resposta correta. Quando Stringse liga ao tipo errado, pode deixar os desenvolvedores depurando por horas, arquivando bugs na equipe do compilador e geralmente perdendo tempo que poderia ter sido salvo usando string.

Outra maneira de visualizar a diferença é com este exemplo:

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

Muitos argumentam que, embora essas informações sejam tecnicamente precisas, o uso Stringainda é bom porque é extremamente raro que uma base de código defina um tipo desse nome. Ou que, quando Stringdefinido, é sinal de uma base de código incorreta.

[...]

Você verá que Stringé definido para um número de finalidades completamente válidos: ajudantes reflexão, bibliotecas de serialização, lexers, protocolos, etc ... Para qualquer uma destas bibliotecas Stringvs. stringtem consequências reais dependendo de onde o código é utilizado.

Então lembre-se de quando você vê o debate Stringvs. string, trata-se de semântica, não de estilo. A escolha da string fornece um significado nítido à sua base de código. Escolher Stringnão é errado, mas deixa a porta aberta para surpresas no futuro.

Nota: Copiei / colei a maior parte da postagem do blog por motivos de arquivamento. Eu ignoro algumas partes, por isso recomendo pular e ler a postagem do blog, se puder.