Diskussion:Spaghetticode

Bei diesem Beispiel kann doch Schritt 70 (und folgende) niemals erreicht werden??? Grüße, cjo

10 CLS
20 i = 0
30 i = i + 1
40 PRINT i; " squared = "; i * i
50 IF i >= 10 THEN GOTO 60
60 GOTO 20
70 PRINT "Program Completed."
80 INPUT "Do it Again (j)"; sel$
90 IF sel$ = "j" GOTO 10
100 END (nicht signierter Beitrag von 217.224.78.149 (Diskussion | Beiträge) 20:19, 22. Okt. 2009 (CEST))

Richtig; außerdem bilden die Zeilen 50 und 60 zusammengenommen eine Endlosschleife. Ich finde dieses Beispiel generell etwas unglücklich, weil die verwendeten GOTOs durchaus legale und strukturierte Konstrukte (Verschachtelung fußgesteuerter Schleifen) abbilden. CU & mfg -- IBinDaBeda 18:38, 27. Okt. 2009 (CET)

Hauptproblem ist halt, dass man Spaghetticode nicht wirklich mit einem kurzen Beispiel erklären kann. Es sollten schon mehr als eine Handvoll bedingte Sprünge zu Programmteilen sein, von denen aus wieder munter weitergesprungen wird. --213.221.250.85 17:59, 7. Dez. 2010 (CET)

Warum sollen Switch-Case Anweisungen ein Indiz Spaghetticode sein? Ich kenne keinen Programmierer der das so sieht, im Gegenteil das ist doch viel übersichtlicher als viele if-else Anweisungen zu verschachteln. (nicht signierter Beitrag von 216.59.6.199 (Diskussion) 15:12, 1. Jan. 2011 (CET))

Switch-Case ist ein Indiz für prozeduralen Code. In OO Sprachen sollte es kaum derartige Statements geben (vgl. http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism). In Basic etc. ist das allerdings oft nicht zu vermeiden. --Sebastian.Dietrich ✉ 08:57, 1. Feb. 2012 (CET)

Satz gelöscht

gelöscht: Es ist von Vorteil auf Papier die Ideen zu der Programmierung zu protokollieren. Man kann im Fall der Fälle auf seine Notizen zurückgreifen um sich mit der Konstruktion und Gliederung seines Quellcodes nochmals vertraut zu machen. <- das ist persönliche Meinung, nicht NPOV. Es ist auch praxisfern, da Änderungen / Wartung im Quellcode selbst vorgenommen werden und die "Notizen" dann keine Ähnlichkeit mehr mit dem Code aufweisen. --Cami de Son Duc 12:08, 9. Apr. 2010 (CEST)

Das ist in der Praxis sehr wünschenswert wenn man wie oben beschrieben:

...auf Papier die Ideen zu der Programmierung zu protokollieren. Man kann im Fall der Fälle auf seine Notizen zurückgreifen um sich mit der Konstruktion und Gliederung seines Quellcodes nochmals vertraut zu machen.
Das ist ja auch der Job eines Softwarearchitekten....

...es ist auch praxisfern, da Änderungen / Wartung im Quellcode selbst vorgenommen werden und die "Notizen" dann keine Ähnlichkeit mehr mit dem Code aufweisen

Dann ist was in der Qualitätssicherung schiefgelaufen. Denn:

• der Code sagt nur: Wie etwas konkret gemacht wird...
• die Anforderungsspezifikation als Teil der Softwaredokumentation sagt: Weshalb etwas genau so gemacht werden muss...

Die Ideen zu der Programmierung sind eine Arbeitsgrundlage für die konkrtete programmtechische Umsetzung und damit Bestandteil der Dokumentation während der Codierung. Diese Unterlagen dürfen zum Abschluss der Codierung weder mit der vorliegenden Codestruktur noch der Anforderungsspezifikation wiedersprechen, sie dienen in der Regel als Basis zum Test und für die spätere Freigabe der Software.... (nicht signierter Beitrag von 109.43.4.234 (Diskussion) 6. Mai 2012, 13:09 Uhr)

Bitte signiere Deine Beiträge mit --~~~~--

In der Praxis funktioniert Dokumentation nicht (egal ob auf Papier oder elektronisch, in Dokumentationssystemen oder in Form von Code-Dokumentation). Das schlussendlich entstandene System ist in der IT in 100% der Fälle ausschliesslich im Code korrekt dokumentiert. Alle anderen Formen von Dokumentation (vor allem auch Anforderungsspezifikationen) sind unvollständig, widersprüchlich, falsch und veraltet. Statt Zeit und Geld für sinnlose Dokumentation auszugeben sollte man sich lieber überlegen, wie man die Anforderungen / Architekturen / Designs anders als durch Dokumentation definieren könnte. Ansätze dafür sind Behavior Driven Development, Architektur-Einhaltung-Prüftools, Test Driven Development etc. --Sebastian.Dietrich ✉ 00:13, 7. Mai 2012 (CEST)

Sebastian.Dietrich ✉ 00:03, 7. Mai 2012 (CEST)

Sorry Benutzer:Sebastian.Dietrich,

wenn eine Dokumentation nicht plausibel ist, dann stimmt zunächst die Arbeitsweise in der Softwareentwicklung nicht!

Der unbefriedigende Zustand der Dokumentation und erhebliche Abweichungn zur Impementation :ist in der Praxis ein recht guter Indikator für Mängel im Softwareentwicklungsprozess...

Das schlussendlich entstandene System ist in der IT in 100% der Fälle ausschliesslich im 
Code korrekt dokumentiert..

Das ist aus QS und prozesstechnischer Sicht leider falsch, weil der Code nur sagt so ist das.

Genau diese Aussage kann nicht zum Nachweis einer fachlich (d.h. den Anforderungen :entsprechenden) korrekten Impementation herangezogen werden.

In der Regel beinhaltet der Code keine oder nicht ausreichende Beispiele

ev. nur einzelne Testfälle, die selbst keine Aussage über die Qualität des Endproduktes zulassen

Du kannst eine Schwimmweste aus Blei nach ISO 900x fertigen, wenn die tragende Funktion nicht geprüft und spezifiziert wird.

Genau so wie Du korrekausfürbaren Code erstellen kannst, der trotzdem aus fachlichen Gründen :(z.B. fehlerhafte Verwendung von Eigenschaften und Funktionen) nicht verwendet werden. kann...

Du als Softwareentwickler wirst verantwortlich gemacht, wenn Du zur Codeerstellung weist,

das Dein Code, den Du produziertst, falsch oder schädlich ist.

Der Nachweis wird anhand der Dir vorliegenden Anforderungen, Testfälle und Projektdokumetation geführt und mit Deinen Code verglichen.

Deshalb soltest Du nicht nur auf korrekten Code, sondern auch im eigenen Interresse auf eine aktuelle plausible Dokumetation bestehen, da Du nur so wissen kanst, ob Dein Code (Handeln) korrekt war und ist.

Dein Wunsch nach QS-Software und Prüftools usw. ist nett, deckt praktisch den Prozess nicht vollständig ab, aber:

Du hast Dich mit Deinen Arbeitsvertrag zum sorgfältigen Handeln verplichtet. Auch die Ausrede, ich habe es nicht gewust, schützt bei Gericht vor Strafen nicht, wenn Du es hättest besser wissen können. --77.25.84.172 09:37, 21. Feb. 2013 (CET)

Zeig mir ein einziges Projekt, bei dem die Dokumentation mit dem IST übereinstimmt. Das IST findest immer nur im Code, in der Dokumentation steht wenn dann nur eine eingeschränkte Sicht von Halbwahrheiten über eine frühere Version der Software.

Zeig mir ein einziges Projekt in dem die Dokumentation das SOLL ausreichend beschreibt. Das SOLL ist a) eine sich ständig ändernde Richtung, Dokumentation ist somit immer veraltet und b) kann eine Dokumentation das SOLL niemals ausreichend beschreiben, es sei denn du verwendest formale Spezifikation

Zeig mir ein einziges Projekt in dem die Dokumentation mehr gelesen als geschrieben wird.

Zeig mir einen einzigen Entwickler, dem auf Grund der Dokumentation vor Gericht nachgewiesen wurde, er hätte nicht sorgfältig gehandelt.

Dokumentation reicht auch nicht aus, um einen Nachweis einer fachlich korrekten Implementierung zu bieten - dazu brauchst formale Spezifikation & Verifikation

Dokumentation hilft vielleicht Fehler zu finden, doch auf Grund der Veralterung und Schwammigkeit der Dokumentation findest damit nur einen Bruchteil der Fehler bzw. viele false positives.

Dokumentation ist somit sauteuer und hilft nur wenig. - Da bringt es niemandem etwas, auf noch mehr und noch bessere Dokumentation zu bestehen. "More of the same" ist eine Sackgasse.

Darum geht agile Softwareentwicklung weg von Dokumentation ("Working software over comprehensive documentation") und verwendet andere Techniken, die weitaus hilfreicher sind. Schau mal nach bei Behavior Driven Development oder Test Driven Development - das sind echte Alternativen - wesentlich sorgfältiger als schwammige, teure, meist nutzlose Dokumentation. --Sebastian.Dietrich ✉ 10:26, 21. Feb. 2013 (CET)

Hallo Sebastian.Dietrich, hast Du schon für Behörden mit erhöhen Sicherheitsbedürfnis, in der Medizintechnik, in der Entwicklung von kritischen Echtzeitsteuerungen z.B. SPS-Hardware oder für die Luft- und Raumfahrt gearbeitet? Ich verstehe als Dokumenttion die Gesammtheit aller Unterlagen die Aufgabe, die Validierung der Aufgabe und die Umsetzung der Aufgabe hinreichend detailiert beschreiben.

Dokumentation ist somit sauteuer das stimmt durch aus!!!

und hilft nur wenig behauptest Du "More of the same" ist eine Sackgasse. behauptest Du...

Ich kenne nicht alle Dramen und Katastrophen in dem "Softwarezirkus", wo der Entwickler gerne ""Schuld"" sein darf, weil andere zuvor keine klare Sprache finden konnten ;)

Die agile Softwareentwicklung geht nicht weg von der Dokumentation und Spezifikation, sondern fordert nur agil permanent verkaufbare Ergebnisse von den Entwicklern ein. Das ist nur eine moderne konsequente Form des Ausquetschens der letzten Reserven in der SW-Entwicklung.

Die Überschrift über dem Agilen Manifest ist ja toll:

Individuen und Interaktionen gelten mehr als Prozesse und Tools
Working Software über umfangreiche Dokumentation
Zusammenarbeit mit dem Kunden steht über Verträgen

Welcher große externe Kunde lebt und akzeptiert wirtschaftlich erfolgreich das agile Vorgehen in den obengenannten Bereichen? Ich kenne noch keinen? Außerem kollidiert das auch noch mit einigen bestehenden populären Rechtsauffassungen;((

Das IST findest immer nur im Code, in der Dokumentation steht wenn dann nur eine eingeschränkte Sicht von Halbwahrheiten über eine frühere Version der Software. Dieser Zustand ist genau das Problem, aber nicht die Lösung der Probleme bei Dokumentation und der Validierung! :)

Wenn man dieses Problem versuchen wollte zu lösen, und es Richtig zu machen will, dann muss man die testgetriebne validierbare Spezifikation, Dokumentation und Codeerstellung als Gesammtheit begreifen und beginnen daran zu arbeiten...  :) Die Wiki Systeme werden auch inder Softwareentwicklung stärker kommen...

Ich kenne es so, bevor nicht mehr entwicklungsbegleitend getestet wird, muss die Dokumentation abgenommen (d.h auf Plausibilität getestet;) sein, dann sind Testdaten und zuletzt der Code drann...

Auch Software nach Clean Code kann Schaden anrichten ;)

Wir werden sehen, was die nächsten Jahren an Erfahrung und Selbsteingeständnissen von Mängeln im Prozess der Softwareentwicklung praktisch bringen und was man wirklich "besser machen" wird und wo wirtschaftliche "Zwänge" dem im Wege stehen... ;)--77.24.5.121 22:34, 21. Feb. 2013 (CET)

Gutes Beispiel

Ich hab zufällig gerade ein hervorragendes und trotzdem kurzes Beispiel für Spaghetti-Code gefunden: [1]

goto b:
a:
goto c;
b:
goto d;
c:
retrun;
d:
goto a;

Obwohl es recht kurz ist, ist es unmöglich den Ablauf mit einem Blick zu erfassen. Ich denke das ist es was einen wirklichen Spaghetti-Code ausmacht: Mehrere Sprunganweisungen hin und zurück über den Code. Das bei diesem Beispiel auf andere Befehle wie PRINT oder INPUT verzichtet wurde ist nur von Vorteil, da damit nicht vom wesentlichen abgelenkt wird. -- Stefan 07:59, 11. Mai 2011 (CEST) (ohne Benutzername signierter Beitrag von 91.46.25.245 (Diskussion) )

Beispiel Nr.1

Um mal den Artikel zu zitieren:

Das nachfolgende simple Basic-Programm gibt die Zahlen 1 bis 10 zusammen mit dem jeweiligen Quadrat auf dem Bildschirm aus. Die verworrenen GOTO-Anweisungen machen es schwierig, den Ablauf des Programms nachzuvollziehen.

Das folgende Programm ist deutlich strukturierter und führt dieselbe Funktion aus:

Kein gutes Beispiel. Das GOTO erzeugt hierbei eine Schleife. Sie ist übersichtlich, klar strukturiert und für einen Außenstehenden ohne Informationen über die verwendete Sprache und deren Syntax auch deutlich leichter verständlicher als das nachfolgende Beispiel. Dieses Beispiel macht nicht das Problem mit GOTO-Anweisungen deutlich, sondern zeigt die möglichen Vorteile. Dxr-Cnx (Diskussion) 16:28, 21. Mär. 2012 (CET)

Zwischen Assembler und Prozedurale Programmierung

Ich denke, man sollte mehr hervorheben, das Spaghetticode historisch begründet ist. In Maschinencode/ Assembler (Informatik) sind Sprungmarken üblich (besser unumgänglich). Abgelöst wurde das durch Prozedurale Programmierung. Das höhere Sprachen heute noch Sprungmarken erlauben, ist hingegen unerträglich. -- Gerold (Diskussion) 18:41, 31. Okt. 2015 (CET)

Objektorientiert Programmierung

Objektorientiert Programmierung wird im Artikel als Gegenmaßnahme gegen Spaghetti-Code genannt. Da habe ich aber schon Beispiele gesehen, die man eher als eigene Form von Spaghetti-Code ansehen muss: Wenn der Programmfluss ständig in der Vererbungshierarchie hinauf und hinunter läuft ist das bei Betrachtung des Quellcodes keineswegs übersichtlich. (nicht signierter Beitrag von 80.157.182.27 (Diskussion) 16:51, 26. Apr. 2022 (CEST))

In der OO wird der Programmfluss nur selten die Vererbungshierarchie rauflaufen und nur bei Polymorphismus runterlaufen. Viel eher geht der Programmfluss (wie auch bei Nicht-OO-Sprachen) in andere Funktionen/Methoden z.B. in verwendete Frameworks/Libraries. Darum ist ein typischer Stacktrace auch meist im Detail nicht interessant und der Programmfluss wird von Entwicklern nur innerhalb der einzelnen Methode betrachtet.

D.h. nicht OO, sondern die Verwendung von Frameworks/Libraries (die ja nötig ist um produktiv entwickeln zu können) macht den Programmfluss unübersichtlich. Der Quellcode ist aber genau aus diesem Grund wesentlich übersichtlicher. --Sebastian.Dietrich  ✉  18:04, 27. Apr. 2022 (CEST)