Chapter 09 — Stringy features

Purpose of this chapter: get fluent with modern “string-facing” features: interpolated strings (including formatting and culture) and nameof for refactor-safe identifiers.

9.1 Recap: string formatting and localization

Before interpolated strings, formatting commonly used composite format strings:

Console.WriteLine("Price: {0,9:C}", price);
// index 0, alignment 9 (right), format string "C" (currency)

Alignment and format strings

Inside {index[,alignment][:format]}:

• index chooses which argument to format.
• alignment sets minimum width; positive is right-aligned, negative is left-aligned.
• format is type-specific (dates, numbers, etc.).

Localization (CultureInfo / IFormatProvider)

Formatting is culture-sensitive:

• Currency symbols, decimal separators, and date formats change by culture.
• Many formatting APIs accept an IFormatProvider (usually a CultureInfo) to control the culture explicitly.

Interview-ready framing:

• Don’t rely on “current culture” for machine-readable output (logs/protocols).
• For user-facing output, do respect culture (UI, reports, etc.).

9.2 Interpolated string literals

Interpolated strings make formatting less error-prone and more readable:

$"Price: {price,9:C}"

9.2.1 Simple interpolation

• {$"{expr}"} inserts expr formatted with default rules.
• Same culture caveats apply as with string.Format.

9.2.2 Format strings in interpolation

Interpolated expressions support alignment and format specifiers:

$"{birthDate:d}"     // short date
$"{amount,9:C}"      // aligned currency

9.2.3 Interpolated verbatim strings

Combine with verbatim strings for paths/multiline:

$@"C:\Users\{user}\Documents"

9.3 Localization using FormattableString

Interpolated strings can be captured as a FormattableString so you can apply a culture later.

Why it matters:

• It separates the “format + arguments” from the final formatted text.
• You can choose invariant culture for logs/telemetry, and a UI culture for user text.

Interview angle:

• In low-latency services, prefer deterministic/invariant formatting for logs and machine protocols.

9.4 Uses, guidelines, and limitations

Guidelines:

• Great for developer-facing strings (logs, diagnostics).
• Be careful with user-facing localization: format with the correct culture and avoid hard-coded concatenation.

Limitations / gotchas:

• Don’t embed secrets/PII via interpolation into logs.
• Avoid building expensive strings eagerly if they’ll be discarded; prefer structured logging where possible.

9.5 Accessing identifiers with nameof

nameof returns the name of a symbol as a string, but is refactor-safe:

throw new ArgumentNullException(nameof(customerId));

Where it shines:

• Argument validation (ArgumentNullException, ArgumentException).
• Property names in notifications (e.g., INotifyPropertyChanged).
• Logging/diagnostics without fragile string literals.

Interview nuance:

• nameof is compile-time; it doesn’t evaluate runtime values.