C#..Warum sollte man Literale in der Programmierung vermeiden?
Literale sind laut meinen Infos Konstanten und feste größen. Vielleicht kann jemand etwas dazu ergänzen. Eine Frage ist halt warum man diese am besten vermeiden sollte.
Vielleicht hätte da jemand noch eine Antwort auf diese Frage. LG und vielen Dank!
3 Antworten
Literale sind keine Konstanten. Sie werden aber beim complieren wie eine Konstante behandelt.
Literal:
foo1(99);
foo2(99);
Konstante:
const bar = 99;
foo1(bar);
foo2(bar);
Der Vorteil der Konstante ist, dass man solche fixen Werte nicht im gesamten Quellcode suchen muss, sondern zu Beginn einer Prozedur. Des weiteren verdeutlicht der Name der Konstante den Zweck. Zudem wird z. B. im obigen Beispiel Speicher für den Wert nur einmal belegt (Optimierungen durch den Compiler mal aussen vor gelassen)
Am Ende ist die Zuweisung an die Konstante auch ein Literal. Es geht also wirklich nur um Vermeidung/Minimierung, nicht Eleminimierung.
Da hast du wohl etwas falsch verstanden. So ganz allgemein ist das natürlich Unsinn. An gewissen Stellen brauchst du einfach Zahlen.
Was gemeint sein könnte ist, dass keine "Magic Numbers" verwendet werden sollten. Zum Beispiel wenn ein Benutzer auswählen soll ob er via Sofortüberweisung oder auf Rechung zahlen will. Dann sollte da sim Code nicht durch eine "1" bzw eine "2" dargestellt sein. Das versteht nämlich keiner.
Literale sind Werte (Zahlen oder Strings), denen man keinen Namen gegeben hat.
Das hat folgende Nachteile, wenn man ein und denselben dieser Werte an mehreren Stellen im Programm benötigt:
- Wenn du dich irgendwo vertippst, kann der Compiler dich auf diesen Fehler nicht aufmerksam machen. Irgendwann wunderst du dich dann, warum dein Programm falsche Ergebnisse liefert. Du wirst Fehler dieser Art dann sehr lange zu suchen haben.
- Wenn du irgendwann später dem Literal anderen Wert geben willst, musst du alle Stellen suchen, an denen du es eingesetzt hast.
Mindestens aus diesen beiden Gründen (es gibt noch andere), sollte man jedem Literal einen Namen geben, d.h. es als Konstante deklarieren, so dass sein Wert nur ein einziges Mal (eben in dieser Deklaration) hinzuschreiben ist.
Das gilt nur für ganz winzige Programme (wie man sie in der Schule schreibt).
Was aber machst du, wenn der Fehler in einer Schleife enthalten ist und sich erst bemerkbar macht, nachdem sie (nach Programmstart) schon mehrere 1000 Mal durchlaufen wurde? Glaubst du wirklich, es sei praktikabel, dann noch mit Breakpoints, d.h. mit einem Debugger zu arbeiten?
Natürlich nicht. Aber wenn es eine Schleife wäre, würdest du den Wert recht früh verhauen und dieser abweichen.
Sonst hättest du sehr unpraktikabel programmiert.
Apropos, ich schreibe auch große Programme. ;-) In der Schule bin ich lange nicht mehr.
Und zumeist (natürlich nicht immer) sind Breakpoints mehr als ausreichend.
Wenn die Werte zum Beispiel über eine Schnittstelle falsch raus kommen. :o)
Aber praktisch fällt mir nichts ein, was auf den eigenen Code zurückzuführen ist.
... oder man mit Speicheradressen rechnet (zum Absturz kommt es erst, wenn die falsch errechnet Adresse über den für den Anwendungsprozess reservierten Speicher hinausgreift). Hast wohl noch nicht viel mit C++ programmiert?
Nein, bin unter C#, Java, PowerShell und SQL unterwegs.
Eher Endnutzerorientiert. Aber dazu gehört auch die Datensammlung.
Also keinerlei Maschinensteuerung o.Ä.
Ansonsten musst du ja nicht groß für den regulären Endnutzer Adressen berechnen.
Verstehe. Wer mit C# oder Java unterwegs ist, kann natürlich gar keine (ungemeldeten) Speicheradressierungsfehler machen. Aber dennoch jede Menge logischer Fehler, die immer erst zuschlagen, wenn man das Rechenergebnis — oft sehr viel später im Programmablauf —benötigt.
Und logische Fehler meldet dir auch kein Debugger. Sie führen nicht selten einfach nur zu einem falschen Rechenergebnis. Insofern sind Fehler, die das Programm zum Absturz bringen, noch wirklich die harmloseren. Sie werden ja meist noch vom Programmierer selbst entdeckt.
Ja, das weiß ich. ;-)
Aber zumindest dort reicht der Breakpoint alle Male, weil zumindest ich nicht zu lange mit Werten herumhantiere und sie im Speicher lasse.
Wie gesagt: Es gibt Fehler, die kein Debugger entdecken kann: Denke mal an Geldbeträge, die errechnet werden, aber falsch, wenn man irgendwo eine Konstante vertippt hat (das aber nur an einer Stelle im Programm, die selten durchlaufen wird). Hätte man jener Konstanten einen Namen gegeben, wäre der Fehler — da dann ja i.A. auch an anderen Stellen des Programms präsent — deutlich früher entdeckt worden.
Ja gut, aber bei einer guten IDE geht das ja recht fix.
Aber klar; wenn du nicht ständig Literale nutzt, geht die Fehlersuche so oder so wesentlich schneller.
Du meinst wohl: "... wenn du ständig (statt nicht ständig) Literale nutzt, erleichtert das die Fehlersuche".
Oh, ja. Entschuldige. Da war ich mit dem halben Kopf dabei. x)
Naja, solange du weißt, wo du den richtigen Wert haben willst, kannst du ihn auch für gewöhnlich zurückverfolgen über Breakpoints.