Interpolasi String vs String.Format

114

Apakah ada perbedaan kinerja yang mencolok antara penggunaan interpolasi string:

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

vs String.Format ()?

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

Saya hanya bertanya karena Resharper meminta perbaikan, dan saya telah dibodohi sebelumnya.

— Krythic
sumber

Mengapa tidak mencoba keduanya dan melihat apakah Anda melihat perbedaannya?

— Blorgbeard keluar

@Blorgbeard Jujur saja, saya malas. Dan saya pikir itu akan memakan waktu lebih sedikit jika salah satu dari Anda, pria / wanita terhormat, tahu jawabannya begitu saja.

— Krythic

Saya suka bagaimana ketika saya pertama kali menanyakan pertanyaan ini, itu mendapat suara rendah untuk dilupakan dan sekarang, dua tahun kemudian, hingga +21.

— Krythic

Sungguh. Bagaimana orang bisa meragukan kegunaan pertanyaan ini? Dapatkah Anda membayangkan total jam kerja yang terbuang , jika setiap orang yang mengajukan pertanyaan ini harus 'mencobanya sendiri dan melihatnya?' Meskipun hanya membutuhkan waktu 5 menit, kalikan dengan 10.000+ pengembang yang telah melihat pertanyaan ini sejauh ini. Lalu apa yang Anda lakukan saat rekan kerja meragukan hasil Anda? Lakukan semuanya lagi? Atau mungkin hanya merujuk mereka ke posting SO ini. Untuk itulah.

— BTownTKD

@BTownTKD Itulah perilaku Stackoverflow khas untuk Anda. Jika ada yang menggunakan situs untuk tujuan yang dimaksudkan, mereka segera diasingkan. Ini juga salah satu alasan mengapa menurut saya kita harus diizinkan untuk memblokir akun secara kolektif. Banyak orang tidak pantas berada di situs ini.

— Krythic

Jawaban:

Yang penting adalah relatif. Namun: interpolasi string diubah menjadi string.Format()pada waktu kompilasi sehingga mereka akan mendapatkan hasil yang sama.

Ada perbedaan halus: seperti yang bisa kita katakan dari pertanyaan ini , penggabungan string dalam format specifier menghasilkan string.Concat()panggilan tambahan .

— Jeroen Vannevel
sumber

Sebenarnya, interpolasi string dapat dikompilasi menjadi rangkaian string dalam beberapa kasus (misalnya saat a intdigunakan). var a = "hello"; var b = $"{a} world";mengkompilasi ke rangkaian string. var a = "hello"; var b = $"{a} world {1}";dikompilasi ke format string.

— Omar Muscatello

interpolasi string diubah menjadi string.Format () pada saat kompilasi.

Juga dalam string. Format Anda dapat menentukan beberapa keluaran untuk satu argumen, dan format keluaran yang berbeda untuk satu argumen. Tapi interpolasi string lebih mudah dibaca, saya kira. Jadi terserah kamu.

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

Ada beberapa hasil uji kinerja https://koukia.ca/string-interpolation-vs-string-format-string-concat-and-string-builder-performance-benchmarks-c1dad38032a

— Paul
sumber

interpolasi string terkadang berubah menjadi String::Format. dan terkadang menjadi String::Concat. Dan pengujian performa pada halaman itu tidak terlalu berarti: jumlah argumen yang Anda berikan ke masing-masing metode tersebut bergantung. concat tidak selalu yang tercepat, pembuat string tidak selalu yang paling lambat.

— Matthias Burger

Pertanyaannya adalah tentang kinerja, namun judulnya hanya mengatakan "vs", jadi saya merasa harus menambahkan beberapa poin lagi, beberapa di antaranya bersifat opini.

Lokalisasi
- Interpolasi string tidak dapat dilokalkan karena sifat kode sebarisnya. Sebelum pelokalan diubah menjadi string.Format. Namun, ada alat untuk itu (misalnya ReSharper).
Maintainability (pendapat saya)
- string.Formatjauh lebih mudah dibaca, karena berfokus pada kalimat yang ingin saya ucapkan, misalnya saat membuat pesan kesalahan yang bagus dan bermakna. Menggunakan {N}placeholder memberi saya lebih banyak fleksibilitas dan lebih mudah untuk memodifikasinya nanti.
- Selain itu, penentu format sebaris dalam interploation mudah salah dibaca, dan mudah dihapus bersama dengan ekspresi selama perubahan.
- Saat menggunakan ekspresi yang kompleks dan panjang, interpolasi dengan cepat menjadi lebih sulit untuk dibaca dan dipertahankan, jadi dalam pengertian ini interpolasi tidak dapat diskalakan dengan baik saat kode berkembang dan menjadi lebih kompleks. string.Formatjauh lebih tidak rentan terhadap hal ini.
- Pada akhirnya, ini semua tentang pemisahan perhatian: Saya tidak suka mencampuradukkan bagaimana hal itu harus disajikan dengan apa yang harus disajikan .

Jadi berdasarkan ini saya memutuskan untuk tetap menggunakan string.Formatdi sebagian besar kode saya. Namun, saya telah menyiapkan metode ekstensi untuk mendapatkan cara pengkodean yang lebih lancar yang lebih saya sukai. Implementasi ekstensi adalah satu baris, dan terlihat seperti ini sedang digunakan.

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

Interpolasi adalah fitur hebat, jangan salah paham. Tapi IMO itu bersinar yang terbaik dalam bahasa-bahasa yang kehilangan string.Formatfitur -like, misalnya JavaScript.

— Zoltán Tamási
sumber

Terima kasih telah menambahkan ini.

— Krythic

Saya tidak setuju pada pemeliharaan; diberikan ReSharper membuatnya lebih mudah untuk mencocokkan nilai yang dimasukkan dengan indeks yang sesuai (dan sebaliknya) tetapi saya pikir masih lebih banyak beban kognitif untuk mengetahui apakah {3}X atau Y terutama jika Anda mulai mengatur ulang format Anda. Contoh 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 Terima kasih telah membagikan pemikiran Anda. Anda memiliki poin bagus, namun itu benar hanya jika kita hanya menggunakan variabel lokal yang sederhana dan dinamai dengan baik. Apa yang sering saya lihat adalah ekspresi kompleks, pemanggilan fungsi, apa pun yang dimasukkan ke dalam string interpolasi. Dengan string.Formatsaya pikir Anda jauh lebih rentan terhadap masalah ini. Tapi bagaimanapun, inilah mengapa saya menekankan bahwa ini adalah pendapat saya :)

— Zoltán Tamási