Top 10 Fehler–#3: String-Vergleichsmethoden

4. Juli 2014

Dies ist Teil 3 der kleinen Serie, die ich als Kommentar zum Blog-Beitrag Top 10 Mistakes that C# Programmers Make begonnen habe.

Heute zum Thema…

Common Mistake #3: Using improper or unspecified string comparison methods

Dieser Punkt ist ein klares Plädoyer dafür, bei allen String-Vergleichen die Methoden zu verwenden die Sprache und Region einbeziehen. Dem kann ich nur aus vollem Herzen zustimmen!

Wenn an dieser Aussage überhaupt etwas auszusetzen ist, dann dass Patrick sie zu eng fasst, nur beschränkt auf den Vergleich mit string.Equals (mit Nennung von Compare als Nachsatz). Dieser Punkt gilt aber für alle Vergleichsmethoden, also auch IndexOf, StartsWith, etc. und darüber hinaus auch Formatierungsfunktionen, wie string.Format und “beliebiger Datentyp”.ToString! Weitere Hinweise finden sich auf MSDN.

Und: Dieser Punkt wäre definitiv auf meiner eigene Top 10-Liste weit oben.

Auf der einen Seite weil es notwendig ist…

… zumindest, wenn man nicht ausschließlich im US-amerikanischen Markt unterwegs ist (und damit nicht mit Format-Kollisionen rechnen muss).

Schon wenn man nur für eine Sprache – Deutsch liegt nahe – entwickelt, wird man immer wieder über Situationen stolpern, in denen Daten interpretiert werden müssen, die als Strings vorliegen statt streng typisiert. Typische Kandidaten hat man immer dann, wenn es um Schnittstellen nach außen geht:

  • CSV-Dateien
  • Datenbanken (je nach Konfiguration)
  • REST-Services (z.B. wenn das JSON als String aufbereitet wird)
  • Konfigurationsdateien

Wenn man hier einmal die Information verloren hat, in welcher lokalisierten Form ein Datum vorliegt, kommt man in Teufels Küche.

Auf mehrsprachige Anwendungen muss ich wohl nicht gesondert hinweisen.

… auf der anderen Seite, weil es nervig ist!

Es macht keinen Spaß, immer wieder CultureInfo.InvariantCulture oder StringComparison.CurrentCultureIgnoreCase hinschreiben zu müssen. Also tut man es nicht. Und in Probleme läuft man frei nach Murphy erst dann, wenn die Anwendung eine Zeitlang gelaufen ist. Dann, wenn nicht mehr nachvollziehbar ist, bei welchen der Datumswerte in dieser Tabelle Tag und Monat vertauscht wurden….

Was kann man dagegen tun?

  • Disziplin? Notwendig aber nicht hinreichend. Selbst ein “williger” Entwickler (ich bin das beste Bespiel) muss sich immer wieder daran erinnern.
  • Hilfen! Ich habe mir mittlerweile Code-Snippets geschrieben, die mir die obigen Klassen verfügbar machen, selbst wenn die passende using-Direktive fehlt.
  • Zwang! FxCop bzw. statische Codeanalyse (und eine no-warnings-policy!). Microsoft hat dem Thema eine Kategorie spendiert: Globalization Warnings.