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)

Deine Argumentation ist total hohl. Du stellst Behauptungen auf und verlangst für Gegenteilige Behauptungen Beweise, die gar nicht zu erbringen sind (zumindest nicht auf legale Weise bei Closed Source). Reinstes Verschwörungsmärchengeschwätz. "Darum geht agile Softwareentwicklung weg von Dokumentation"? Tut sie nicht. Was du meinst, ist "Pfusch".

--87.174.42.90 13:54, 22. Nov. 2022 (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)

Ich verstehe die Fixierung auf GOTO-Sprünge nicht.

Inversion of Control / Dependency Injection + massig (selbsterzeugte) Events + für jeden Pups eine eigene Klasse + 2 potenziell wiederverwendbare Zeilen müssen schon eine eigene Methode sein = Spaghetticode vom Allerfeinsten. --87.174.42.90 14:02, 22. Nov. 2022 (CET)

IoC bereinigt Architekturfehler (z.B. zyklische Abhängigkeiten), DI trennt bzw reduziert Code, Events helfen Code zu trennen bzw. asynchron zu machen, eigene Klassen für Pups trennen die Pups, eigene Methoden für 2 potentiell wiederverwendbare Zeilen fordert niemand. Nichts von alldem erhöht Spaghetticode bzw. hat überhaupt was mit Spaghetticode zu tun. Du meinst offensichtlich was anderes. Overengineering? --Sebastian.Dietrich  ✉  17:00, 24. Nov. 2022 (CET)

Unterprogramme statt Spaghetticode

Es geht um folgende Änderung, die mit folgender Begründung durch eine IP gemacht wurde "Formulierung war schlecht. Gesprungen wird immer, auch Unterroutinen verwenden auf Assemblerebene Sprunganweisungen, der Unterschied ist, dass sie zur aufrufenden Funktion wieder geordnet zurückkehren." bzw "Außerdem ist das Problem des Spaghetticode nicht nur auf Hochsprachen begrenzt, man kann auch auf Assembler Spaghettiecode verursachen oder mit Unterroutinen, die dann natürlich händisch umgesetzt sind, strukturiert arbeiten. Deine Änderung war schlecht und hat nicht zur Verbesserung des Artikels beigetragen."

Habe ich wieder zurückgesetzt mit Anmerkung "Darum geht es nicht. Es geht darum, dass man gänzlich ohne Sprunganweisungen (durch z.B. Verwendung von Schleifen oder Unterprogramme) auskommt. Assemblerebene ist hier nicht relevant".

Klar kann man in beliebigen Programmiersprachen Spaghetticode machen, es geht aber um die Aussage, dass es Unterprogramme benötigen würde (die es auf Assemblerebene gar nicht gibt), um Sprunganweisungen zu umgehen. Das ist nicht nur falsch und trifft auch beispielsweise nicht auf das Programmierbeispiel zu, sondern entspricht auch meist nicht der Praxis: Spaghetticode wird meist nicht durch Unterprogramme (Refactoring "Extract Code") sondern durch unterschiedlichste Refactorings aufgelöst. --Sebastian.Dietrich  ✉  08:25, 28. Jul. 2024 (CEST)

Das hier:

es geht aber um die Aussage, dass es Unterprogramme benötigen würde

habe ich überhaupt nicht behauptet, was zeigt dass du es überhaupt nicht verstanden hast. Sondern ich schrieb (fetter Text):

Ein Indiz dafür kann etwa die Verwendung von Sprunganweisungen (wie GOTO) sein, wobei man zum gleichen Ziel auch per Unterprogramme gelangen würde, die wieder geordnet zum aufrufenden Hauptprogramm zurückkehren .

Das auch per steht für ein Beispiel, wie es ohne Sprunganweisungen geht. Das Unterprogramm ist als Beispiel aufgeführt ist. Damit sind also auch alle anderen Kontrollstrukturen berücksichtigt und nicht nur Unterprogramme.

Damit ist präzisiert, was mit diesem "ohne Sprünge" gemeint ist. Denn wenn Nichtprogrammierer das hier lesen, wollen die wissen was Spaghettiecode ist und was damit ohne Sprunganweisung gemeint ist. Also muss ein Beispiel her.

Und das die wieder geordnet zum aufrufenden Hauptprogramm zurückkehren steht dafür, dass das Beispiel Unterprogramm, deswegen kein Spaghetticode ist, weil dieses die Eigenschaft hat geordnet zum aufrufenden Hauptprogramm zurückkehren. Diese Präzisierung anhand des Beispiels Unterprogramme fehlte in der vorherigen Einleitung:

Ein Indiz dafür kann etwa die Verwendung von Sprunganweisungen (wie GOTO) sein, wobei man zum gleichen Ziel auch ohne Sprünge gelangen würde.

Es wird darin nicht beantwortet:

1. Wie das ohne Sprünge gemacht wird.

2. Warum das dann kein Spaghettiecode ist, also der Unterschied wird nicht dargelegt.

Zu:

die es auf Assemblerebene gar nicht gibt

Du kannst auch in Assembler manuell strukturiert programmieren, das sagte ich aber bereits im meinem Edit. Scheinbar hast du nie in Assembler programmiert.

Und dein Äußerung:

Darum geht es nicht. Es geht darum, dass man gänzlich ohne Sprunganweisungen (durch z.B. Verwendung von Schleifen oder Unterprogramme) auskommt. .

ist falsch, weil es halt eben doch genau darum geht, siehe oben, was ich präzisiert habe, was du nicht hattest.

Und das fehlt in der Einleitung, was ich mit mit meinem Edit präzisiert habe. Und um diese Präzisierung, die du nicht verstanden hast, geht es.

Und zu:

Assemblerebene ist hier nicht relevant"

Jede Hochsprache wird in Maschinencode zerlegt, welche man als Vorstufe auch als Assemblercode angucken kann. Der Compiler macht aus einem Unterprogramm also eine Folge von Anweisungen die Sprünge enthalten. Jetzt muss aber erklärt werden, warum das etwas anderes ist, als GOTO, was ich dadurch erklärt habe, dass bspw. Unterprogramme strukturiert zur aufrufenden Funktion zurückkehren. Dein Text war also schlecht, aus den obigen fehlenden Gründen und Angaben 1. und 2. Und deswegen habe ich das verbessert, weil es verbessert werden musste.

Jetzt verstanden? --84.158.120.82 23:00, 28. Jul. 2024 (CEST)

Und im übrigen entfernt man keine Edits, die bereits von anderen gesichtet und somit bestätigt wurden. Es bist also du, der hier einen Editwar fabriziert, weil du es wieder entfernt hast. --84.158.120.82 23:04, 28. Jul. 2024 (CEST)

Generell gilt:

1. Wir befinden uns in der Einleitung des Artikels (wo alles kurz und knackig stehen sollte) und z.B. kein Platz für Beispiele oder unnötige weitere Begriffe ("Unterprogramm", "Hauptprogramm") bzw. sogar Begriffsfindung ("geordnete Rückkehr") ist
2. Es gibt weiter unten einen Abschnitt mit einem Beispiel (das übrigens ohne Unterprogramm auskommt und auch Spaghetticode auf der Assemblerebene erklärt)

Also wenn du unbedingt dein Unterprogramm reinbringen möchtest, dann im Abschnitt Programmierbeispiel. Der Abschnitt ist aber schon relativ lange, vermutlich wirst du keinen Konsens finden, dass hier noch ein weiteres Beispiel (von 100ten möglichen) reingehört.

Dann aber bitte exakter als mit dem Satz: Was z.B. meinst du mit "geordneter" Rückkehr - gibts sowas wie eine ungeordnete Rückkehr? Was ist wenn das Unterprogramm eine "ungeordnete" Exception wirft? Was meinst du mit "Hauptprogramm"? Kann man GOTOs nur in "Hauptprogrammen" schreiben? Können Unterprogramme nur von "Hauptprogrammen" aufgerufen werden?

Das ist alles unnötige, verwirrende Mehrinformation, Begriffsfindung bzw. Falschinformation, die jede WP:OMA nur noch mehr verwirren.

Und übrigens - unterlasse deine lächerlichen WP:PA, Belehrungen und Erfindung von Wikipediaregeln. Damit kommst du in der WP nicht weit. --Sebastian.Dietrich  ✉  09:11, 29. Jul. 2024 (CEST)

Was soll dieser Unsinn?

sogar Begriffsfindung ("geordnete Rückkehr")

Muss ich jetzt dir auch noch die deutsche Sprache erklären?

gibts sowas wie eine ungeordnete Rückkehr?

Soll deine Frage dein ernst sein? Man kann das ganz leicht mit einer Gegenfrage beantworten, hältst du Spaghetticode für strukturierten geordneten Code?

Was meinst du mit "Hauptprogramm"?

Du kannst auch aufrufende Funktion, oder, wenn du Woke Leute ärgern möchtest, auch Masterfunktion und für Unterprogramm dann Slavefunktion schreiben, aber ob das die Laien dann verstehen, ist dann die andere Frage.

Das ist alles unnötige, verwirrende Mehrinformation, Begriffsfindung bzw. Falschinformation,

Ist es nicht. Es ist weder verwirrend, da es präzisierend ist, noch ist es Begriffsfindung, wer der deutschen Sprache mächtig ist, versteht die Wörter und Falschinformation ist es schon einmal gar nicht.

Zu:

die jede WP:Blub

und:

deine WP:Bla

Spar dir den Verweis auf diese Wikipediaseiten, es hält sich in der Wikipedia nachweislich und beweisbar nicht einmal ein Großteil der Moderation an diese Regeln, warum sollten die dann für andere Nutzer gelten? --84.158.120.82 20:17, 29. Jul. 2024 (CEST)

Ok - also weiter WP:PA, Belehrungen, Erfindung von Wikipediaregeln und jetzt auch noch WP:BNS. Darum Ende der Diskussion und der Artikel bleibt wie er ist. Kannst dich ja gerne an die WP:3M wenden oder besser noch eine andere Spielwiese suchen. --Sebastian.Dietrich  ✉  19:12, 30. Jul. 2024 (CEST)

Wie schon gesagt, den Blödsinn von WP:Bla und WP:Blub kannst du dir sparen, ich lese das sowieso nicht, weil sich auch die Moderation daran nicht hält. Was hier aber gar nicht geht sind deine unverschämten Unterstellungen oder Falschbehauptungen, denn Regeln habe ich hier keine erfunden.

Da du unbelehrbar bist, wird es wohl auf eine 3M hinauslaufen. Mal gucken, wann ich dazu komme und ob ich darauf Bock habe. Meine Distanzierung weiter unten von deinem Unsinn steht ja unten und kann da jeder nachlesen. --84.158.120.82 00:28, 31. Jul. 2024 (CEST)

Ich distanziere mich von dem Unsinn den Benutzer:Sebastian.Dietrich hier verursacht hat

Es geht um seinen Edit eines bereits signierten Beitrags. Mit der Signierung wurde er bereits überstimmt und dennoch hat er seinen Unsinn wieder eingebaut. --84.158.120.82 22:36, 28. Jul. 2024 (CEST)

Du kennst offensichtlich die Regeln der Wikipedia nicht. Hier als Service für dich: WP:GSV und WP:Editwar --Sebastian.Dietrich  ✉  08:28, 29. Jul. 2024 (CEST)

Ich habe es schon oben geschrieben, die Moderation hält sich an diese Regeln nachweislich und beweisbar nicht, insofern kannst du dir den Unsinn sparen. Meine Distanzierung von deinem inhaltlich fehlerhaften und falschen Edit bleibt bestehen. --84.158.120.82 20:18, 29. Jul. 2024 (CEST)