4

Recently in C# 6 a new language element/syntactic sugar was introduced named string interpolation.

However after a few minutes of enjoying the sweet taste of this syntax, it quickly turns out, that interpolated strings (what are still string literals in semantic point of view) can not be refactored out to a resource because of the variables embedded are living only that scope where the interpolated string is defined.

This scope locked string literals for example can not be localized and regardless of the localization need, some code quality checkers used to regard string literals embedded in as code smell.

Working with a huge enterprise code base I expect to appear more and more interpolated strings, so the problem will be quickly turn from theoretical to practical. I would like both

  • have a code quality checker rule which bans out this practice just like string literals in the middle of the code (I can manage it, by defining custom rules in the standard quality tools. Although StyleCop currently does not even recognize them, and runs to an internal error, so this will not be as easy as it sounds)
  • have a refactoring tool what can refactor string interpolation to string.Format so then it can easily can refactor out to a standard .NET resource.

Any suggestions

Improve this question
9
  • ReSharper probably allows you to change between the formats. Usually if it can convert from A to B it lets you convert from B to A. Or just write a new Roslyn analyser! Commented Jul 27, 2015 at 8:58
  • @ta.speot.is: Writing a custom code transformation Roslyn seems to be a bit overwhelming task, plus I do no want to reinvent the wheel. Thx anyway Commented Jul 27, 2015 at 9:01
  • What do you mean "automatically"? You want to write a program that will convert interpolated strings to String.Format()? Commented Jul 27, 2015 at 9:03
  • 1
    @sweeper I mean a refactoring tool. Ideally this could check the code base in the build server, but less ideally can refactor this smell project/solution wide by a few click. Commented Jul 27, 2015 at 9:06
  • 1
    Oh never mind ... I see what you're saying. You want the whole string to be localizable ... what would have been String.Format("My Name is {0}", myName) should be String.Format(project.resources.Introduction, myName). Commented Aug 13, 2015 at 21:12

2 Answers 2

Reset to default
2

Enabling code analysis prevents usage of interpolated strings (warning CA1305) as they don't support specifying locale (unlike String.Format). So while somewhat awkward this is possible solution to your particular case.

Also R# can quickly convert one format to another - so while not automated combination of Code Analysis and R# would let you quickly find and partially correct all the cases.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

1

Localisation is possible with string interpolation.

Consider this:

System.FormattableString s = $"Hello, {name}";

s.ToString() will use the current culture to produce the string.

float flt = 3.141;

System.IFormattable s = $"{flt}";

With IFormattable you can alter numeric formats according to specific languages

So it is possible, just not directly.

source:

https://msdn.microsoft.com/nl-nl/library/dn961160.aspx

Improve this answer

1 Comment

Localization is not only about to get the correct decimal separator and other culture specific settings. It is also about to use resources to get language specific versions of strings. My statement was: "can not be refactored out to a resource because of the variables embedded are living only that scope where the interpolated string is defined.", which is true. Using interpolated strings is sweet, but a code smell.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.