Diskussion:Redundanter Code

message: Im Beispiel kann die Division durch 0 zu einem Fehler führen, da das Beispiel in C ist, muss es aber nicht zu einem Laufzeitfehler führen. Warum jetzt pauschal der Code einfach entfernt werden kann, finde ich nicht einleuchtend. Die Entfernung würde unter Umständen den Ablauf ändern. Dass der Code zu entfernen ist, folgt laut Erläuterung des Beispiels gerade daraus, dass eine Ausnahme auftritt. Sollte die Entfernung des toten Codes nicht unabhängig davon gewünscht sein? --Zahnradzacken 17:01, 29. Dez. 2011 (CET)
replies: text: Ich habe das Beispiel mal als Java deklariert. Die auftretende ArithmeticException wäre dann ein Seiteneffekt der Funktion. --Nbuechen 17:28, 29. Dez. 2011 (CET)
replies: text: Machts leider auch nicht richtiger da der Seiteneffekt Exception möglich ist. Und selbst andere Grundrechenarten bewirken unter Umständen die Änderung der Flags C, Z. Vielleicht wählt man lieber ein Beispiel was ohne Zusatzbemerkungen auskommt.--Darktrym (Diskussion) 16:16, 28. Jan. 2015 (CET)
thread_title:  Beispiel 

message: Ich habe mir die für die Definition zitierte Quelle mal angesehen. Dort heißt es „For example, if it is possible for a computation to generate exceptions or raise signals whose handling can affect the behavior of the rest of the program, then we cannot consider that computation to be dead.“
Also das Gegenteil von dem, was sich im Artikel an die Definition anschließt ("kann er Ausnahmebehandlungen auslösen"). --Zahnradzacken 17:21, 29. Dez. 2011 (CET)
replies: text: So ganz sauber ist der englische Artikel auch nicht. Gemeint ist aber wohl ein "nicht gewollter" Seiteneffekt, den man hier unterstellen muss. --N. Büchen 17:32, 29. Dez. 2011 (CET)
replies: text: Dann wäre der tote Code also "ungewollt" doch nicht toter Code. Und mit der Beschreibung des Beispiels ist das in beiden Sprachversionen nicht konsistent. Die Quelle finde ich da überzeugender. Demnach handelt es sich beim Beispiel nur scheinbar um toten Code. Hätte man Multiplikation statt Division (und keinen Überlauf), wäre es tatsächlich toter Code. --Zahnradzacken 17:37, 29. Dez. 2011 (CET)
replies: text: Ich glaube die Definition ist selbst in den Quellen nicht konsistent. Die letzte Quelle beschreibt eher unereichbaren Code. Ich denke, man muss die Quellenrecherche fortsetzen. --N. Büchen 19:10, 29. Dez. 2011 (CET)

text: Ich habe den QS-Baustein gesetzt, da innerhalb der Artikel Dead code elimination auch schon unerreichbarem Code gemeint ist. Die Definitionen sollten entsprechend dem Sprachgebrauch der Quellen angepasst werden. Unter umständen muss man von mehreren verschiedenen Definitionen ausgehen. --N. Büchen 19:25, 29. Dez. 2011 (CET)
thread_title:  Definition 

message: Ich sehe hier drei disjunkte Programmiersünden
# Code, der ausgeführt wird, aber dessen Ergebnisse nicht benutzt werden
# Code der nie ausgeführt wird
# Code der doppelt vorkommt
Auch die Definition von totem Code im Artikel zweifel ich an. Es ist eher 2 als 1 und das deckt sich beispielsweise mit 
* https://www.google.de/search?tbm=bks&hl=de&q=%22Toter+Code%22
Im Grunde fußt der ganze Artikel auf Theoriefindung. Ich habe mal den Baustein überarbeiten gesetzt. --Siehe-auch-Löscher (Diskussion) 08:31, 7. Dez. 2015 (CET)
replies: text: Grundsätzlich Zustimmung. Jedoch halte ich 1. nicht für redundanten Code, sondern einfach für einen Programmfehler (-schwäche). 2. ist im engeren Sinn (redundant = mehrfach) keine Redundanz, sondern nur, wenn man 'redundant mit 'überflüssig' gleichsetzt; aber auch hier dürfte ein Programmfehler oder eine andere Absicht vorliegen. Ich denke aber, dass man den derzeit fehlenden Aspekt 3. einfach im Text unterbringen kann. Punkt 2 zu korrigieren wäre etwas anderes. --VÖRBY (Diskussion) 10:16, 7. Dez. 2015 (CET)
replies: text:  Ich stimme Dir zu, den Begriff redundanter Code würde ich nur für 3 verwenden. Auf diesen Artikel bezogen sollten wir überlegen, was man mit den 3 Punkten macht, ein Artikel, drei Artikel und jeweils welche Lemma? --Siehe-auch-Löscher (Diskussion) 11:45, 7. Dez. 2015 (CET)
thread_title:  Überarbeiten 

message: * Hier gibt es zwei Grundlinien, die bisher möglicherweise unzulässig vermengt wurden.
** Außerdem ist „Redundanter Code“ kein scharf umrissener Begriff mit über Jahrzehnte einheitlich anzutreffender Verwendung, sondern wird auch von Koryphäen und reputablen Standardwerken mal enger gefasst, mal breiter gesehen.
# Toter Code, unerreichbarer Code, wirkungsloser Code
#* Das kann Rückstand früherer oder Vorgriff auf zukünftig geplante Programmierungen sein.
#** In C & Co. kann man Debugging-Aktivitäten und Ansätze zukünftiger Weiterentwicklungen elegant aus der Produktivversion raushalten.
#** In Java und vielen anderen Sprachen geht das nicht. Hier kann man auskommentieren oder lediglich zu Wartungs- und Kontrollzwecken eingefügte Prozeduren von einer Konfigurationsvariablen abhängig machen oder schlicht in ein if(false) setzen; in der Hoffnung, dass der Compiler das dann gar nicht erst in den generierten Code aufnimmt.
#* Überreste früher sinnvoller Programmierungen kann man vorsichtig nach und nach herausoperieren, aber das ist vielleicht noch nicht überall abgeschlossen, während man die Notwendigkeit hatte, bereits mit einer Produktivversion rüberzukommen, die andere benötigte Neuerungen enthält.
#* Weiterentwicklungen können ansatzweise vorhanden sein, ihre Ergebnisse im Testmodus kontrolliert werden, aber man musste auch hier schon mit einer Produktivversion öffentlich werden, bevor die neuen Features für alle Anwender wirksam werden.
#* Wirkungsloser Code muss nicht nur deshalb scheinbar wirkungslos sein, weil die direkten Ergebnisse nicht verwertet werden.
#** Man kann eine Million Mal vom Datenträger lesen und/oder an dieselbe Stelle dasselbe schreiben; nur um produktiv oder zu Entwicklungszwecken das Zeitverhalten zu ermitteln. Das Ergebnis der Leseoperation wird verworfen. Abhängig vom Zeitverhalten kann man sich dann in bestimmte Modi konfigurieren.
#** Man kann nach Art eines ping Netzwerkoperationen ausführen oder Systemaktivitäten anschubsen. Dabei will man diese Aktion selbst gar nicht haben, sondern wartet auf das Versagen; kommt keines, dann kann man den weiteren Verlauf anders strukturieren, und wenn es nicht funktioniert, kann man geeignet modifiziert fortsetzen.
# Redundanter = doppelter Code
#* Man kann mit Doppelprogrammierungen eine Absicht verbinden.
#* Man kann beabsichtigen, getrennte Module, die gleiche Funktionen enthalten, aber zurzeit innerhalb eines Paketes verwendet werden, unabhängig voneinander belassen, damit sie bei zuküftiger Einzelverwendung nicht eines dritten Blocks mit einer Bibliothek gemeinsam benutzter Funktionen bedürfen.
#* Allgemein sollten Aktivitäten, die vorhersehbar der Wartung und Pflege bedürfen, zentral an einen Punkt konzentriert werden, um Doppelarbeit und Inkonsistenzen zu vermeiden. Das sind alle Stellen, wo die Außen- und Anwendungswelt auf die innere Struktur abgebildet wird; da ändert sich öfter mal was.
#* Mathematische Verfahren funktionieren über Jahrtausende gleich. Man kann das komplette Verfahren etwa zur Nullstellensuche austauschen, aber die Rechenschritte innerhalb müssen nur selten umgeschrieben werden. Der Satz des Pythagoras braucht nicht deshalb eine zentrale Bibliotheksfunktion, weil sich die Formel mal ändern könnte und man das neue Berechnungsverfahren einpflegen müsse.
#* Aus Performancegründen werden insbesondere zeitkritische Schleifen oft ohne Bibliotheksfunktionen direkt kodiert.
#** Wenn man in Echtzeit die Millisekunden eines Audiostreams oder ein einzelnes Pixel eines Videospieles ausrechnet, dann geizt man.
#** Jeder Aufruf einer Funktion kostet Zeit und zusätzliche Schritte; Frame allokieren, Platz für innere Variablen allokieren, Argumente auf innere Variablen abbilden, Ergebnis ausrechnen und für Zielstelle einsetzen, wieder alles deallokieren.
#** Wer weiß, dass er eine 2D- oder 3D-Matrizenmultiplikation vor sich hat, der braucht keine flexible zentrale Bibliotheksfunktion für n-Matrizen, sondern kann das Ergebnis ausmultipliziert hinschreiben. In C kann man das elegant einmal in ein Makro packen, ansonsten meist nicht.
#* Alle Überlegungen zur Vermeidung von Doppelarbeit rechnen sich erst ab einer gewissen Komplexität. Es wird nicht schneller oder verständlicher, wenn man in einer prozeduralen Funktion jede paar Programmzeilen in einen Funktionsaufruf auslagert und die Anzahl der Zeilen damit drückt, auch wenn irgendwelche Metrik-Deppen das als Inbegriff der Kunst feiern.
* Allgemein gilt, was VÖRBY weiter oben schon richtig angemerkt hatte: Redundant ist, was keine besondere Absicht verfolgt, nur überflüssiger Überrest früherer Parallelentwicklungen ist. In dem Moment, in dem man aus guten Gründen sich für eine formal redundante Vorgehensweise entscheidet und dies in der Zukunft ausgenutzt werden soll, ist der Begriff nicht mehr anwendbar.
* Hinsichtlich der ins Spiel gedachten Lemma-Aufteilung:
** Der Begriff ist zu schwammig, als dass das gerechtfertigt wäre.
** Es gibt keine verbindliche standardisierende Norm dafür.
** „Toter Code“ und „unerreichbarer Code“ sind in einem Satz zu erklären, rechtfertigen keine eigenen Artikel.
*** Ob es manche Leute gibt, die das als Unterbegriffe und Spezialfälle sehen, und andere, die es als unterscheidbare andere Situationen sehen, steht dahin.
LG --PerfektesChaos 12:20, 7. Dez. 2015 (CET)
replies: text: Hallo - und alle Achtung für die umfassende (und schnelle!) Stellungnahme! Mir gingen solche Gedanken (Bedeutung, Ursachen, Alternativen ...) auch schon durch den Kopf. Allerdings sollten wir erstmal den Artikel richtigstellen, d.h. ihn aus seiner Bedeutung von 'totem Code' befreien. Ich denke, da genügt vorerst einfach das Ergänzen um die wesentliche und praktisch bedeutsamste Definition, nämlich redundant = mehrfach. In einem eigenen Abschnitt kann man ja dann, vlt. später, detailliertere Aspekte ergänzen. Ja, die ausführliche Abhandlung von t.C. könnte man vorläufig kürzen - bis zu den vorgenannten weiteren Vertiefungen. 'Belege' sollten bei allem nicht vergessen werden. --VÖRBY (Diskussion) 12:57, 7. Dez. 2015 (CET)

text: Ich habe in der Einleitung die erste vorläufige Ergänzung mal vorgenommen. Wie weit die späteren Kapitel den Aspekt 'mehrfach' behandeln oder nur den toten/unerreichbaren Code, habe ich noch nicht ermittelt. Ein Redigieren könnte / sollte nachfolgen, auch Ergänzungen wie die von <PerfChaos 12:20, 7. Dez>. --VÖRBY (Diskussion) 13:44, 7. Dez. 2015 (CET)
thread_title:  Stellungnahme 

message: * Testabdeckung
Wie lautet der spezielle Zusamenhang zu totem oder redundatem Code? --Siehe-auch-Löscher (Diskussion) 14:54, 6. Dez. 2015 (CET)
thread_title:  Siehe auch 

message: Nur weil manche toten Code fälschlich als "redundant" (statt obsolet, nicht erreichbar oder noch nicht aktiviert) bezeichnen, gehört das m.M.n. hier so nicht rein.--Mideal (Diskussion) 21:12, 28. Jul. 2020 (CEST)
replies: text: Der tote Code aus dem Beispiel ist übrigens aktiv und damit nicht tot, und außerdem nicht in Zeile 2.--Mideal (Diskussion) 21:17, 28. Jul. 2020 (CEST)
thread_title:  Redundanz vs. Toter Code