Einzelne Buchstaben färben in C#?

1 Antwort

Ich mach's mal für die erste Zeile.

/* In normaler Farbe schreiben */
System.Console.Write("Die Fläche des Quadrates beträgt ")

/* Bisherige Farbe speichern und neue Farbe (hier: rot) setzen. */
System.ConsoleColor originalColor = System.Console.ForegroundColor;
System.Console.ForegroundColor = System.ConsoleColor.Red;

/* Das Ergebnis "richtig" in einen String umwandeln und ausgeben. (Das Verhalten der Default-Umwandlung ist von der Betriebssystemsprache abhängig, was man in der Regel *NICHT* möchte!) */
String quadratstring = quadratergebnis.ToString(System.Globalization.CultureInfo.InvariantCulture);
System.Console.Write(quadratstring);

/* "Alte" Farbe wiederherstellen und den Rest schreiben. */
System.Console.ForeGroundColor = originalColor;
System.Console.Write(" m².");

Ich hab das jetzt nicht getestet, aber wenn das nicht funktioniert, dann ist es vermutlich überhaupt nicht möglich.

Das mit der "Sprachabhängigkeit per Default" ist übrigens eines der größten "Probleme" von .NET. Ich sehe es als eine enorme Fehlerquelle, weil viele Entwickler sich dessen vermutlich nicht bewusst sind.

In die andere Richtung gilt übrigens das selbe. In der Regel möchte man ...

int i = System.Int32.Parse(someString, System.Globalization.CultureInfo.InvariantCulture)

... anstatt ...

int i = System.Int32.Parse(someString);

Hier wird implizit etwas gemacht, das meines Erachtens nur dann passieren sollte, wenn der Entwickler es auch tatsächlich möchte (und somit bewusst hinschreibt).

Microsoft hat das leider umgedreht. Wenn man etwas (nämlich sprachabhängige Umwandlung) nicht möchte, muss man einen optionalen Parameter angeben. Das ist meines Erachtens extrem schlechtes API-Design. Zumindest sollte man sich als Entwickler darüber bewusst sein, weil man sonst plötzlich Code schreibt, der sich auf anderen Systemen plötzlich anders verhält und z. B. eine Datei, die auf einem System erzeugt wurde, auf einem anderen nicht mehr lesen kann oder auf einem System eine Eingabe akzeptiert und auf einem anderen nicht.

NoHumanBeing  24.05.2016, 10:29

Errata:

Bitte noch ein paar Semikolons "einstreuen", die ich offensichtlich vergessen habe. (In der zweiten Zeile der ersten Box und in der zweiten Box.)

Und "string" bitte klein schreiben.

Und "ForegroundColor", nicht "ForeGroundColor".

;-)

1
PWolff  24.05.2016, 13:21
@NoHumanBeing

"String" und "string" sind in C# Aliasse für denselben ICL-Klassennamen, sind also völlig austauschbar. (Trotzdem ist es guter Stil, sich auf eine Schreibweise zu beschränken.)

Microsoft hat das leider umgedreht. Wenn man etwas (nämlich sprachabhängige Umwandlung) nicht möchte, muss man einen optionalen Parameter angeben. Das ist meines Erachtens extrem schlechtes API-Design.

Microsoft hat das leider umgedreht. Wenn man etwas (nämlich sprachabhängige Umwandlung) nicht möchte, muss man einen optionalen Parameter angeben. Das ist meines Erachtens extrem schlechtes API-Design.

Über solche Dinge rege ich mich auch regelmäßig auf. Ich vermute stark, dass das ein Erbe aus der ersten VBA-Zeit ist, wo auch ein Laie das Gefühl haben sollte, er könnte programmieren, weil er etwas zusammenhacken kann, was einigermaßen das tut, was er will.

1
NoHumanBeing  24.05.2016, 16:45
@PWolff

"String" und "string" sind in C# Aliasse für denselben ICL-Klassennamen, sind also völlig austauschbar. (Trotzdem ist es guter Stil, sich auf eine Schreibweise zu beschränken.)

Nein, es ist nicht austauschbar. Die Klasse heißt vollqualifiziert "System.String" und das muss ich auch angeben, sofern ich kein "using System;" mache.

Mir ist bekannt, dass Visual Studio das automatisch einfügt, allerdings empfinde ich persönlich "using"-Statements als extrem schlechten Stil, weil sie den gesamten Namensraum "hereinholen". Dabei kann es immer zu Konflikten kommen. Deswegen ist so ziemlich das erste, was ich mache, nachdem ich eine neue Quellcodedatei in Visual Studio erstellt habe, alle "using"-Statements zu entfernen.

Ich würde "using" benutzen, wenn ich einzelne Klassen aus einem Namensraum importieren könnte, so wie Java ja beispielsweise ein "import javax.swing.JOptionPane;" erlaubt. (Ich würde in Java niemals "import javax.swing.*;" verwenden. "import something.*;" ist aber genau das, was die Anweisung "using Something;" in C-Sharp macht.) Aber in der Form, wie "using" momentan implementiert ist, ist es für mich schlechter Programmierstil und daher kommen für mich im Moment nur vollqualifizierte Namen in Frage. Außerdem weiß man viel eher, worüber man spricht und was für einen Typen man dort gerade tatsächlich "an der Hand hat", wenn man den vollqualifizierten Namen angibt, weil der nunmal eindeutig ist.

Auf "using namespace X;" in C++ trifft übrigens das selbe zu. Da schreibe ich lieber "std::cout", "std::cin", "std::endl", "std::memcpy", "std::int32_t", etc., anstatt mir meinen Namensraum durch die Standardbibliothek "vollmüllen" zu lassen. Als netter Nebeneffekt wird so auch gleich dokumentiert, dass das, was ich dort verwende oder aufrufe, zur Standardbibliothek gehört.

Über solche Dinge rege ich mich auch regelmäßig auf. Ich vermute stark, dass das ein Erbe aus der ersten VBA-Zeit ist, wo auch ein Laie das Gefühl haben sollte, er könnte programmieren, weil er etwas zusammenhacken kann, was einigermaßen das tut, was er will.

Das kann gut sein, ja.

Allerdings ist .NET ja im Grunde eine sehr viel professionellere Plattform. Es ist ja im Prinzip vielmehr mit Java vergleichbar (und macht meines Erachtens sogar einiges besser, aber Java ist eben auch älter).

0
Asonger 
Fragesteller
 24.05.2016, 10:31

Vielen Dank für diese ausführliche Antwort!

Ich werde mal schauen.

Grüße.

1