Closed yaakov-h closed 1 year ago
On the one hand, I agree with the general idea of this rule, on the other hand I have used this very technique to avoid creating an overload of a method that takes a string
(because the string overload would break the usage of the FormattableString
overload.)
I would probably also classify $"{foo}"
as pointless when the overall expression result will be a string (instead of FormattableString).
That's a good point, we would only want to flag it when the receiver is of type string
- particularly as the C# team are also looking into other types of formattable string builders for high-perf.
We could also be fancy and try detect overloads but that might be a bit much.
I agree on $"{foo}"
.
Occasionally I come across people using interpolated strings as a way of concatenating strings.
eg. $"{foo}{bar}"
where both foo and bar are strings, should be foo + bar
instead.
though this could lead down a rabbit warren and I'm not sure where to draw the line.
$"{foo}|{bar}"
feels like it should be foo + "|" + bar
, but $"{foo} not found in {bar}"
feels like it should remain an interpolated string.
It looks like C# is already making that conversion for us, so it's really just down to which conveys semantics better.
C# is also getting constant interpolated strings and other significant improvements to interpolated strings next month, so I'm tempted to leave them as they are if they are actually doing some interpolation.
i.e.
$"this string has no format specifiers"
, including$@
/@$
variations.