String Interpolation vs String.Format

113

Existe uma diferença de desempenho perceptível entre o uso de interpolação de string:

myString += $"{x:x2}";

vs String.Format ()?

myString += String.Format("{0:x2}", x);

Só estou perguntando porque o Resharper está solicitando a correção, e eu já fui enganado antes.

— Krythic
fonte

Por que não experimentar os dois e ver se nota a diferença?

— Blorgbeard será lançado em

@Blorgbeard Honestamente, sou preguiçoso. E eu acho que levaria menos tempo se um de vocês homens / mulheres honrados soubesse a resposta de imediato.

— Krythic 01 de

Eu adoro como, quando fiz essa pergunta pela primeira vez, ela foi votada contra o esquecimento e agora, dois anos depois, está para +21.

— Krythic

Seriamente. Como alguém pode duvidar da utilidade desta pergunta? Você pode imaginar a perda total de horas de trabalho, se todos que fazem esta pergunta tivessem que 'tentar por si próprios e ver?' Mesmo que tenha levado apenas 5 minutos, multiplique isso entre os mais de 10.000 desenvolvedores que viram esta pergunta até agora. E então o que você faz quando um colega duvida de seus resultados? Fazer tudo de novo? Ou talvez apenas encaminhe-os para este post do SO. É meio para isso que existe.

— BTownTKD

@BTownTKD Esse é o comportamento típico do Stackoverflow para você. Se alguém usar o site para o fim a que se destina, será imediatamente alienado. Essa também é uma das razões pelas quais acho que devemos ter permissão para banir contas coletivamente. Muitas pessoas simplesmente não merecem estar neste site.

— Krythic,

Respostas:

Notável é relativo. No entanto: a interpolação de strings é transformada em string.Format()tempo de compilação, então elas devem terminar com o mesmo resultado.

No entanto, existem diferenças sutis: como podemos dizer a partir dessa pergunta, a concatenação de string no especificador de formato resulta em uma string.Concat()chamada adicional .

— Jeroen Vannevel
fonte

Na verdade, a interpolação de string pode ser compilada em concatenação de string em alguns casos (por exemplo, quando um inté usado). var a = "hello"; var b = $"{a} world";compila para concatenação de string. var a = "hello"; var b = $"{a} world {1}";compila para o formato de string.

— Omar Muscatello

a interpolação de string é transformada em string.Format () em tempo de compilação.

Também em string.Format, você pode especificar várias saídas para um único argumento e diferentes formatos de saída para um único argumento. Mas a interpolação de strings é mais legível, eu acho. Então a escolha é sua.

a = string.Format("Due date is {0:M/d/yy} at {0:h:mm}", someComplexObject.someObject.someProperty);

b = $"Due date is {someComplexObject.someObject.someProperty:M/d/yy} at {someComplexObject.someObject.someProperty:h:mm}";

Existem alguns resultados de teste de desempenho https://koukia.ca/string-interpolation-vs-string-format-string-concat-and-string-builder-performance-benchmarks-c1dad38032a

— Paulo
fonte

a interpolação de strings às vezes é transformada em String::Format. e às vezes em String::Concat. E o teste de desempenho nessa página não é realmente significativo: a quantidade de argumentos que você passa para cada um desses métodos é dependente. concat nem sempre é o mais rápido, stringbuilder nem sempre é o mais lento.

— Matthias Burger,

A questão era sobre o desempenho, no entanto, o título diz apenas "vs", então eu sinto que tenho que adicionar mais alguns pontos, embora alguns deles sejam opinativos.

Localização
- A interpolação de string não pode ser localizada devido à sua natureza de código embutido. Antes da localização, ele foi transformado em string.Format. No entanto, existem ferramentas para isso (por exemplo ReSharper).
Capacidade de manutenção (minha opinião)
- string.Formaté muito mais legível, pois se concentra na frase que eu gostaria de formular, por exemplo, ao construir uma mensagem de erro agradável e significativa. Usar os {N}marcadores de posição me dá mais flexibilidade e é mais fácil modificá-lo posteriormente.
- Além disso, o especificador de formato embutido na interpretação é fácil de mal interpretado e fácil de deletar junto com a expressão durante uma mudança.
- Ao usar expressões complexas e longas, a interpolação rapidamente se torna ainda mais difícil de ler e manter, portanto, nesse sentido, ela não é escalonada bem quando o código está evoluindo e fica mais complexo. string.Formaté muito menos sujeito a isso.
- Afinal de contas, tudo se resume a separação de preocupações: não gosto de misturar o como deve ser apresentado com o que deve ser apresentado .

Portanto, com base nisso, decidi manter a string.Formatmaior parte do meu código. No entanto, preparei um método de extensão para ter uma forma de codificação mais fluente da qual gosto muito mais. A implementação da extensão é de uma linha e parece simplesmente assim em uso.

var myErrorMessage = "Value must be less than {0:0.00} for field {1}".FormatWith(maximum, fieldName);

A interpolação é um ótimo recurso, não me interpretem mal. Mas, IMO, ele brilha melhor nas linguagens que não string.Formatpossuem o recurso semelhante, por exemplo, JavaScript.

— Zoltán Tamási
fonte

Obrigado por adicionar a isso.

— Krythic

Eu discordo sobre sustentabilidade; O ReSharper concedido torna um pouco mais fácil combinar os valores inseridos com seus índices correspondentes (e vice-versa), mas acho que ainda é mais carga cognitiva descobrir se {3}é X ou Y, especialmente se você começar a reorganizar seu formato. Exemplo de Madlibs: $"It was a {adjective} day in {month} when I {didSomething}"vs string.Format("It was a {0} day in {1} when I {2}", adjective, month, didSomething)-> $"I {didSomething} on a {adjective} {month} day"vsstring.Format("I {2} on a {0} {1} day", adjective, month, didSomething)

— drzaus

@drzaus Obrigado por compartilhar suas idéias. Você tem bons pontos, no entanto, só é verdade se usarmos apenas variáveis locais simples e bem nomeadas. O que tenho visto muitas vezes são expressões complexas, chamadas de função, o que quer que seja colocado em strings interpoladas. Com string.Formateu acho que você está muito menos sujeito a esse problema. Mas enfim, é por isso que enfatizei que é minha opinião :)

— Zoltán Tamási