Diskussion:Redundanter Code

Beispiel

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)

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)

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)

Definition

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)

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)

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)

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)

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)

Unerreichbarer Code

Setzt der nicht zwingend voraus das Sprünge von der Architektur unterstützt werden? Vielleicht sollte man das mal erwähnen.--Darktrym (Diskussion) 16:18, 28. Jan. 2015 (CET)

Ich denke nicht, dass unerreichbarer Code nur in Architekturen/Sprachen mit Sprüngen existieren kann. Voraussetzungen sind denke ich nichtmal Entscheidungen. Vielleicht findest aber irgendwo einen Beleg dafür, welche Sprachen/Architekturen unerreichbaren Code (oder sogar toten Code) verhindern können. --Sebastian.Dietrich ✉ 17:42, 28. Jan. 2015 (CET)

Naja, theoretisch gesehen kann es toten Code nur geben, wenn das Steuerwerk/Prozessor Sprünge im Programm ausführen kann. Insofern stimmt das.

Aber solch eine Architektur könnte ein Programm nur linear von vorn nach hinten ausführen, es gäbe keine bedingten Anweisungen und keine Schleifen - aber auch keinen toten Code. Existiert sowas überhaupt?--Plankton314 (Diskussion) 20:36, 28. Jan. 2015 (CET)

Meine Sicht zu 'redundantem Code' ist eine ganz andere: Nämlich wenn es identischen Code mehrfach gibt. Zum Beispiel wenn eine Fehlerbehandlungsroutine im code x-fach 'offen programmiert' ist - anstatt eine zentrale Unterroutine dafür zu verwenden. Ich denke, solche Fälle werden in erster Linie als 'Redundanz' bezeichnet - und sind ein Zeichen für suboptimalen Code, weil man im Fall erforderlicher Änderungen an mehreren Stellen dasselbe ändern muss. Das gilt sogar quellcode-übergreifend; weshalb man z.B. Unterprogramme oder IncludeAnweisungen benutzen kann/soll.

Toter Code wäre in diesem Sinn (so sieht es wohl auch Wikipedia:Redundanz) eigentlich nicht redundant, sondern nur eine spezielle Ausprägung von 'überflüssig', zu der aber - gerade in der Programmierung - insbesondere der von mir genannte Aspekt gehört, aber hier nicht behandelt wird. --VÖRBY (Diskussion) 16:29, 4. Dez. 2015 (CET)

Deine Sicht deckt sich mit einschlägiger Literatur:

• https://www.google.de/search?tbm=bks&hl=de&q=%22Redundanten+Code%22
• https://www.google.de/search?tbm=bks&hl=de&q=%22Redundanten+Programmcode%22

Ich denke bei dem Begriff auch an Copy-Paste-Programmierung oder mehrfacher Implementierung gleicher Funktionalität. --Siehe-auch-Löscher (Diskussion) 15:21, 6. Dez. 2015 (CET)

Danke. Dann sollten wir also diesen Aspekt und die Belege dafür im Artikel einstellen. 'Toter Code' kann aber nur deshalb als 'redundant' gelten, weil er auch 'überflüssig' ist, auch wenn er nicht 'mehrfach' auftritt. Computerlexikon definiert: "öfter vorhanden als eigentlich nötig", könnte also T.C. einschließen. Aber: Ich denke, T.C. ist eher ein Aspekt des Testens (Programmfehler?), vielleicht noch des (bewussten = nicht problematischen) 'temporären Deponierens' von Codeteilen im Quellcode.

Ich werde das mal angehen. --VÖRBY (Diskussion) 15:43, 6. Dez. 2015 (CET)

Überarbeiten

Ich sehe hier drei disjunkte Programmiersünden

1. Code, der ausgeführt wird, aber dessen Ergebnisse nicht benutzt werden
2. Code der nie ausgeführt wird
3. 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)

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)

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)

Stellungnahme

• 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.

1. 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.
2. 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)

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)

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)

Redundanter Code soll nur ein Mangel sein?

Den einleitenden Satz "Redundanter Code ist in der Programmierung der Begriff für Quelltext bzw. Teile eines Computerprogramms, die überflüssig sind" halte ich in dieser Unbedingtheit für falsch.

Auch die im gesamten Artikel folgende Darstellung von redundantem Code als Code, der aus der Entwicklungszeit irgendwie fehlerhaft verblieben und unbedingt mit praktischen (Java-)Tools aufzuspüren und zu entfernen ist, kann ich nicht nachvollziehen. Zudem bezeichnet nach meiner Meinung "toter Code" nicht synonym "redundanten Code", auch wenn im Artikel weit überwiegend davon die Rede ist.

Es ist zwar schon einige Jahre her, aber ich kann mich gut daran erinnern, dass ich mich zum Auslesen von Prozessdaten aus Registern gelegentlich von der C++-Ebene in die Niederungen der Assemblercodierung begab und dort ganz bewusst redundanten Code produzierte. Unterprogrammaufrufe mit den zugehörigen Stack- und Registersicherungs- sowie -restaurierungsoperationen hätten sonst meine Bemühungen zunichte gemacht.

Ungewollte Coderedundanzen (nicht! toter Code) ergaben sich oft, wenn mehrere Entwickler an ähnlichen Aufgabenstellungen des gemeinsamen Entwicklungsprojektes arbeiteten und dank mangelhafter Abstimmung/Koordination unnötigerweise ähnliche Submodule entwickelten und bereitstellten.

Kann es sein, dass solche Probleme und Zusammenhänge heute nicht mehr existieren und es deshalb tatsächlich keine guten Gründe für Coderedundanzen mehr gibt oder wurde im Artikel zu wenig auf Allgemeingültigkeit geachtet? Grüße --losch (Diskussion) 21:20, 4. Dez. 2015 (CET)

Das was du meinst ist doppelter Code (Copy&Paste-Code) und nicht redundanter Code. Doppelter Code gilt zwar genauso als "smell" - d.h. sollte dringend entfernt werden, da er nur unnötigerweise die Bugs und Wartungskosten hochtreibt - allerdings erst ab einer gewissen Größe (eine einzelne 2x im Programm vorkommende Zeile wird man z.B. nicht entfernen) und auch nicht in jeder Programmiersprache (bei nicht-OO kann das u.U. nicht funktionieren). Redundanter Code ist aber immer Code den man ohne Nebeneffekte (bis auf Zeitverhalten) löschen kann --Sebastian.Dietrich ✉ 11:59, 5. Dez. 2015 (CET)

Doppelt oder redundant - m.E. kann das hier als Synonym gelten. Lt. Computerlexikon 2012 [1] bedeutet 'redundant' "öfter vorhanden als eigentlich nötig". Was dabei 'nötig' ist, wäre wieder eine andere Frage: Ja, x-mal einen bestimmten Befehl zu codieren, ist sicher meist unkritisch; wenn es aber eine ganze 'Routine' ist, wird es besonders dann kritisch, wenn in diesem Codeteil Änderungen möglich/wahrscheinlich sind. Dann wäre, um Redundanz zu vermeiden, eine Variante von Modularisierung angebracht, entweder im Quelltext selbst als Unterroutine oder - über mehrere Programme hinweg - durch Verwenden der Include-Technik (bei der die Redundanz (im Zwischen-Quellcode mehrerer Programme) nicht relevant ist) oder eine andere Form von Unterprogramm.

Jedenfalls beschreibt der derzeitige Text nicht sauber, was r.C. ist. Und dass Toter Code und Redundanz nahezu gleichgesetzt werden, ist erst recht ungenügend; siehe mein Disk-Beitrag (16:29, 4. Dez. 2015) im vorheriger Abschnitt.--VÖRBY (Diskussion) 12:24, 5. Dez. 2015 (CET)

Siehe auch

• Testabdeckung

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

Quelltextklon redundant

Der Inhalt in Quelltextklon und die Bedeutung 'mehrfach vorhandener Code' hier im Lemma sind WP-Redundanz, die eliminiert werden sollte. Hab das jetzt erst gesehen. HIER wurde ursprünglich i.W. Toter Code behandelt, was aber dem Lemmatitel nicht entsprach. Deshalb sollte der Artikel oder nur sein Inhalt nach 'Toter Code' verschoben (= Umbenannt) werden. Die darin zuletzt ergänzte Bedeutung 'mehrfach vorhanden' sollte dann wieder entfernt oder nur als Link oder bei 'Siehe auch' erwähnt werden. 'Redundanter Code' sollte dann eine BKS werden, die auf beide Artikel verweist. Allerdings halte ich 'Quelltextklon' nicht für eine sehr gängige Bezeichnung. Meinungen? --VÖRBY (Diskussion) 11:20, 15. Dez. 2015 (CET)

Aber: Unter 'Klon' versteht Klon (Informationstechnik) etwas absichtlich Nachgebautes, redundanter Code entsteht dagegen meist aus anderen Gründen (auch Fehler). 'Klon' würde damit etwas Redundantes heißen, wenn es aus bestimmten, nachvollziehbaren Gründen geschaffen wurde. 'Redundanter Code' müsste demnach in mehrere Teilbegriffe zerfallen.

PS: In der BKS Klon fehlt 'Quelltextklon'. --VÖRBY (Diskussion) 12:48, 15. Dez. 2015 (CET)

D.h. "Redundanter Code" -> "Toter Code", "Quelltextklon" -> "Doppelter Code" ? Wäre dafür... --Sebastian.Dietrich ✉ 19:38, 16. Dez. 2015 (CET)

Und dann gibt es noch Don’t repeat yourself --Siehe-auch-Löscher (Diskussion) 21:21, 16. Dez. 2015 (CET)

Dieses Lemma wäre dann zu löschen, ggf. nach Rettung einzelner Aussagen nach 'Dopelter Code'.--VÖRBY (Diskussion) 10:04, 17. Dez. 2015 (CET)

@Sebastian: Dann aus "Toter Code" die 'mehrfach'-Aussagen entfernen. Und diese ggf. bei "doppelter Code" (besser ..Quelltext?) einfügen. Plus neue BKS für "Redundanter Code"; dieser Ausdruck muss erhalten bleiben, sollte aber nach Lage der Dinge auf zwei unterchiedliche Lemmas verweisen.--VÖRBY (Diskussion) 10:04, 17. Dez. 2015 (CET)

Bitte lasst dieses Lemma in Ruhe, gliedert nichts aus, verschiebt nichts in der Gegend herum.

• Der Begriff „Redundanter Code“ hat keine standardisierte Bedeutung; er wird seit Jahrzehnten weltweit mal mit dieser, mal in jener Interpretation benutzt.
• Es gibt keinerlei Institution, die für den ganzen Planeten festlegen würde, wie man das verstehen müsse und was dazugehören würde und was nicht.
• Es gibt eine engere und eine weitere Auslegung; wie das halt so kommt, wenn Hunderttausende von Fachleuten einen undefinierten Begriff benutzt haben. Für jede Variante lassen sich etliche Quellen finden.
• So, wie der Artikel jetzt aufgebaut ist, kann man prima die unterschiedlichen Situationen geschlossen behandeln. Zerstückelt man das in Mini-Artikel, dann muss man alle dreimal erzählen. Das wäre redundant.

„Redundant“ heißt ganz einfach ‚überflüssig‘ oder ‚sinnlos‘.

• Und ‚überflüssig‘ bedeutet: Mindestens einmal häufiger vorhanden als benötigt oder sinnvoll.
• Für ‚überflüssig‘ gibt es zwei Fälle:
  1. 0× benötigt, 1× vorhanden.
  2. 1× benötigt, 2× vorhanden oder auch n×.
• Die erste Situation ist diejenige, bei der Code im Moment nicht erreichbar ist (soll vielleicht zukünftig oder in bestimmten Situationen passieren?) oder scheinbar wirkungslos, weil das Ergebnis nicht ausgewertet wird (hat aber vielleicht andere Effekte, etwa zur Simulation von Vorgängen, zum Provozieren von System-Antworten, zur Auslastung von Ressourcen).
• Die zweite Situation ist diejenige, bei der formal Code mehrfach vorhanden ist; was möglicherweise ein Einsparungspotential ausmacht. Vielleicht wäre es aber auch Schwachsinn, da ranzugehen.

Nehmen wir mal ein Beispiel für jedes; ich hatte schon einen Abschnitt vorher einiges aufgezählt.

1. Wir haben unser eigenes Anwendungsprogramm, und dazu eine Bibliothek von draußen.
   • In der Programmbibliothek mögen 123 Funktionen vorhanden sein.
   • Von den 123 Funktionen benutzen wir momentan 19.
   • Dann sind 104 Funktionen „unerreichbarer“ Code. Völlig redundant.
   • Die kann man jetzt herauslöschen, ohne Schaden anzurichten. Unser Obersystemschlauberger macht jetzt genau das.
   • Danach komme ich als Anwendungsprogrammierer und benutze die 20. Funktion aus der Programmbibliothek. Peng. Absturz. Anschließend werde ich den Systemschlaumeier jagen und mit CPU-Kühlern grillen.
   • Inzwischen kommt die neue Version der Programmbibliothek mit nunmehr 145 teilweise verbesserten Funktionen heraus und ersetzt die Vorgängerversion. Was jetzt? Diesmal 125 „unerreichbare“ Funktionen löschen?
2. Wir haben zwei Funktionsblöcke in unserem Programmsystem: Modul-A und Modul-B.
   • In beiden gibt es einige Standardfunktionen; vielleicht zum fortgeschrittenen Trimmen von Zeichenketten oder zur Zahlendarstellung, aber jedenfalls „doppelt“.
   • Wir entscheiden uns dafür, ein neues Modul-LIB zu begründen und tun da unsere Standardfunktionen hinein, und specken unsere Modul-A und Modul-B dafür ab.
   • Kurz darauf entscheidet sich unser Chef, als Schnupperversion die Einzelpakete A und B separat zu reduziertem Preis herauszugeben.
   • Problem: A ist jetzt nicht mehr lauffähig ohne LIB, und B ist nicht mehr lauffähig ohne LIB. In LIB steht jetzt aber auch das teuere Know-How, das wir nicht herausgeben und kostenlos pflegen wollten. Hätten wir die paar Funktionen einfach in Ruhe gelassen, wären A und B unabhängig geblieben.

Beim dem Themenfeld „Redundanter Code“ kommt es auf etwas ganz anderes an: Dass die Redundanz momentan keine Absicht verfolgt und auch in Zukunft keinen Sinn mehr haben wird.

• Ob etwas 0× benötigt oder 1× benötigt wird und dann 2× oder n× vorhanden wäre, ist nachrangig.
• Das formale Sich-festbeißen an Redundanz erinnert mich an die unzähligen Fälle, in denen man Technische Redundanz nicht begriffen hatte. Also die Leute, die Prüfziffern für überflüssig halten, weil es ja auch ohne funktioniert; die darüber lästern, dass an Autos und Fahrrädern zwei Bremssysteme vorhanden seien, wo doch eines davon völlig redundant wäre; und warum Jetpiloten einen Fallschirm und Schleudersitz hätten, diese aber nie benutzen würden. Fallbacks, Backups, Cache und diverse andere sind Beispiele für absichtsvolle Redundanz in der IT.

Entscheidend ist nicht die Frage, wie oft etwas im Moment vorhanden ist, sondern wie oft es in Zukunft benötigt werden wird.

• In einem über viele Jahre und aus unabhängigen Systemen zusammengewachsenen Gesamtpaket stecken immer allerlei Redundanzen. Es gehört zur Weisheit, einige erstmal zu belassen und andere, die wirklich stören, vorrangig zu beseitigen, was aber erstmal hohen Aufwand erfordern kann, bis danach wieder alles robust funktioniert.
• Genau wie bei dem Gedöns um Metriken und deren blinder Einsatz ist es bei der gnadenlosen Ausmerzung von Klonen. Wenn sie statisch sind und voraussichtlich nicht mehr an einer weiteren Stelle benötigt werden, kann es sinnvoll sein, sie zu belassen, statt eine neutrale Neuentwicklung zu starten, die dann parametrisiert werden muss, weil dann doch nicht in vollem Umfang absolut identisch. Ist hingegen absehbar, das hier häufig Neuerungen eingepflegt werden müssen, sollte man dies zentralisieren.

Der Quelltextklon mag geeignete Teile und Details des umseitigen Artikels tragen, bzw. dorthin als Hauptartikel verwiesen werden. Hier sollten dann die strategischen Überlegungen für alle Konstellationen gebündelt werden.

VG --PerfektesChaos 13:48, 20. Dez. 2015 (CET)

Auch aus meiner Sicht wäre 'R.C.' jetzt auch soweit ok. Er verweist als Sonderfall auf 'Toter Code'. Da bliebe nur die Frage, wie man die vorhandene Redundanz zwischen R.C. und 'Quelltextklon' beheben oder reduzieren kann. Und dass 'Klon' nicht passt, weil es als etwas 'absichtlich Nachgebautes' gilt - für das die (negativ besetzte) Bedeutung von Redundanz nicht zutrifft.

Dieser Fall 'Klon' und auch Deine Beispiele könnten als Detailerläuterungen sinnvoll sein. 'Bibliothek' könnte dabei zeigen, dass es zwar auch hier scheinbar 'Überflüssiges' gibt. Da aber 1.) eine Bib kein 'Programm' ist, hat das mit Red. im hier beschriebenen Sinn nichts zu tun. Und 2.): Da man jederzeit die 20. Funktion aufrufen 'kann', kann sowas niemals als Red. gelten, sondern ist einfach nur das wahlweise Nötige.

Was wäre also noch zu tun? Bitte kurz! --VÖRBY (Diskussion) 20:31, 20. Dez. 2015 (CET)

Redundanz vs. Toter Code

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)

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)