Diskussion:Codequalität

Plattformunabhängigkeit

Ich bin mir nicht sicher, ob der Abschnitt zur Plattformunabhängigkeit wirklich in den Artikel passt, hat die Ausführbarkeit von Code doch im eigentlichen Sinne nichts mit der Qualität des Programmierstils im Sinne des restlichen Artikels zu tun... --Jbspeakr (Diskussion) 09:53, 11. Jan. 2013 (CET)

Dem Absatz zu Portierbarkeit liegt ein viel zu enge Definition davon zugrunde. Bei einer Portierung von z.B. Windows nach Linux spielen noch ganz andere Faktoren als die verwendete CPU eine Rolle. Das fängt bei einfachen Dingen wie Pfadangaben an (C:\Windows vs. /usr/bin), geht bei verwendeten APIs weiter (OpenFile vs. open), schließt eventuell Dinge wie verwendetes Windowingsystem ein (Windows vs. X11) und hört damit sicher nicht auf. Und Portierbarkeit in diesem Sinne wird auch durch Codequalität beeinflusst: Z.B. Verwendung von Konstanten oder klare Kapselung von plattformabhängigen APIs, ... Danke und Gruss, --S.K. (Diskussion) 05:24, 2. Feb. 2013 (CET)

Dieser Abschnitt ist HIER in diesem Artikel m.E. unberechtigterweise enthalten, aber aus anderen Gründen als es Jbspeakr oben meint: Es geht hier um Codequalität - und damit um das Erfüllen von Anforderungen (an den Code). Da ist der Aspekt Portierbarkeit einfach nur einer von vielen und Bedarf keiner besonderen Behandlung - außer, man würde das für alle Anforderungen so tun. Das sieht aber der Artikel derzeit nicht so, er geht sogar davon aus, dass nur die funktionale Seite des Codes durch 'Anforderungen' bestimmt wird - was paradox wäre, denn Qualität heißt nichts anderes als 'Erfüllen von Anforderungen'.

Siehe auch die Diskussion zu #Definition / Belege - wo ich u.a. die Redundanz zu Programmierstil monierte. Diese Disk. ist noch nicht abgeschlossen. Gruß von --VÖRBY (Diskussion) 10:56, 2. Feb. 2013 (CET)

Software-Metriken, Refactoring und andere Lücken

In der Einleitung werden Software-Metriken genannt, im Artikel fehlt ein entsprechender Abshnitt aber bislang. Es gibt doch sicher einige automatische Verfahren, um Code-Qualität zumindest einschätzen zu können. Außerdem fehlen Verbindungen zu den Artikeln Refactoring und Code-Review. Auch ein Beispiel wäre nett (z.B. Fakultätsberechnung in Sauber und in Spagetticode zum Vergleich) Ansonsten schöner Artikel. -- Nichtich (Diskussion) 11:36, 14. Jan. 2013 (CET)

Code-Analyse

Ich schlage vor, einen neuen Unterpunkt 'Code-Analyse' zu integrieren, der die zahlreichen Kriterien für Mangelfreiheit von Code benennt, kurz beschreibt und ggf. verlinkt. Hier gibt es zur Zeit Überschneidungen im aktuellen 'Kriterien'-Abschnitt. --Jbspeakr (Diskussion) 11:03, 30. Jan. 2013 (CET)

Es gibt bereits Statische Code-Analyse. Weiteres sollte bitte erst nach Klärung hier (Redundanz zu Programmierstil?) in Angriff genommen werden. --VÖRBY (Diskussion) 14:27, 30. Jan. 2013 (CET)

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 08:51, 8. Apr. 2013 (CEST)

Rechtliche Bewertung von Code

Ich schlage vor, einen neuen Unterpunkt 'Rechtliche Bewertung von Code' zu integrieren, der die Rechtsbeispiele aus dem iX-Artikel (iX 2/ Februar 2013) 'Qualität nach Maß' von Prof. Horst Eidenberger (TU Wien) aufgreift. --Jbspeakr (Diskussion) 11:04, 30. Jan. 2013 (CET)

Gibts den Artikel wo online? --Sebastian.Dietrich ✉ 08:37, 14. Okt. 2013 (CEST)

Definition / Belege

Die Definition im Artikel und auch die unter #Allgemeines beschriebene Abgrenzung wird bislang nicht 'belegt'. Wörtlich genommen ist Code-Qualität die Qualität des Codes. Daraus lässt sich mE nicht klar ableiten, dass darunter nur ein Teilbereich, nämlich die formalen und strukturellen Eigenschaften (im Artikel wird das 'konkrete Qualität des Quelltexts' genannt; verbesserungsfähig) zu verstehen ist. Ich teile diese Ansicht zwar auch, vermisse aber Belege dazu und würde zusätzlich vorschlagen, dies im Text auch deutlicher zu sagen. Nach bisheriger Beschreibung müsste man einem fehlerbehafteten, aber formal total sauber programmierten Quellcode eine 'gute Code-Qualität' attestieren.
Wer kennt Quellen? --VÖRBY (Diskussion) 11:04, 17. Jan. 2013 (CET)

Zusatz: Inhaltlich halte ich den Artikel für redundant zu Programmierstil. Falls 'Code-Qualität' kein offiziell bestätigter Begriff ist, könnte man die beiden Lemmate zusammenführen und einen der Begriffe als WL einrichten. --VÖRBY (Diskussion) 16:35, 17. Jan. 2013 (CET); präzisiert: --VÖRBY (Diskussion) 09:48, 21. Jan. 2013 (CET)

In den "Standardwerken" Clean Code, Pragmatic Programmer, Refactoring sollte sich was dazu finden lassen, oder auch in diversen Artikeln zu Metriken. Ich schau mal. Der Begriff passt denke ich mit der Beschreibung überein. Sauberer Code, der die Anforderungen _nicht_ erfüllt, hat eine gute Code-Qualität.

Programmierstil ist was anderes - z.B. Einrückungen, Klammernsetzung etc. Programmierstil wird oft (auch im Artikel) verwechselt mit "Stil, in dem eine Software umgesetzt wird" - also z.B. OO oder Prozedural, Agil oder klassisch, ... D.h. das Lemma Programmierstil beschreibt in Programmierstil#Programmierstil_im_weiteren_Sinne eindeutig zuviel (nämlich auch Code-Qualität, Architektur ("Vermeidung von Redundanz – durch Modularisierung", "Einsatz passender API-Komponenten"), Programmierparadigmen, ...). Dieser Absatz gehört mMn zum Teil nach Code-Qualität verschoben, zum Teil nach Archtiektur, etc. Die einzige Literaturangebe in Programmierstil [1] gehört auch zu Code-Qualität (und auch da nur teilweise - z.B. "(9) Rewrite (Planning) - ... Therefore, plan on rewriting your program several times. " gehört zu Projektmanagement oder Best-Practices, aber weder zu Code-Qualität noch zu Programmierstil) --Sebastian.Dietrich ✉ 12:20, 18. Jan. 2013 (CET)

Ich kann ebenfalls keinerlei Redundanz im Gegenstand erkennen.

Programmierstil ist nur ein Faktor unter vielen, die Einfluss auf die Code-Qualität haben können.

Mehrere Programmierstile sind für gleiche Code-Qualität möglich; nur wenn so gar keine Linie erkennbar ist, wird es übel.

• Ein (konsequenter und konsistenter) Programmierstil ist nicht besser oder schlechter als der andere, sondern einfach nur anders. Höchstens kann er für die eine oder andere Aufgabenwelt besser oder weniger geeignet sein.

Andere Faktoren wie konsistente Namensgebung und Notation, problemangepasste Grenzwerte diverser Metriken, nachlesbare Konzeptionen und Strukturen, selbst die Qualität der Dokumentation (auswertbare Code-Dokumentation inline, menschenlesbare Problembeschreibungen außerhalb) gehören zur Code-Qualität, nicht aber zum Programmierstil.

Typografische Standards fallen eher unter Programmierstil (Leerzeilen, Leerzeichen, Einrücken, Klammersetzung).

Die angesprochene Verwechslung ist wohl eine Verwirrung zwischen Programmierparadigma und Programmierstil. Wo der Einleitungssatz wieder konfus ist.

LG --PerfektesChaos 12:45, 18. Jan. 2013 (CET)

Danke erst mal für eure Stellungnahmen. Es geht hier wohl um die Grenzlinien zwischen den Begriffen Softwarequalität im Allgemeinen, Programmierparadigma, Programmierstil und Code-Qualität, evtl. auch noch andere. Wahrscheinlich hat da jeder irgendwie ein Gefühl, eine Meinung dazu (Gefahr der TF!). Meine ist:

1. 'Stil' bedeutet immer irgendwie Art des Tuns - und da passen die Aussagen in Code-Qualität und in Programmierstil problemlos rein - inkl. 'Paradigma' (als übergordnete Bedeutung).
2. Dagegen ist 'Qualität' ein definierter (Erfüllung von Anforderungen) Begriff, der - ohne Zusatz im Lemma - nicht oder höchstens umgangssprachlich auf das Formale (oder die 'Art') reduzierbar ist.
3. Worüber wir hier diskutieren, ist auf jeden Fall eine Teilmenge zu Softwarequalität ...
4. ... und zwar die, die nichts mit den Anforderungen zum 'WAS' zu tun hat, sondern die ausschließlich das WIE betreffen.
5. Die Inhalte zu diesem Teilbegriff (= Anforderungen) sind sehr unterschiedlich, und sie werden im Sprachgebrauch im engeren oder im weiteren Sinn mit unterschiedlichen Ausdrücken bezeichnet.
6. Ich vermute, dass es dafür keinen standardisierten Begriff gibt, sondern dass umgangssprachlich mehrere verwendet werden - mit nicht exakten oder uneinheitlichen Abgrenzungen zueinander.
7. Wenn 'man' dabei eindeutige (und belegte) Grenzen ziehen kann, sollten die Definitionen diese Grenzen je Artikel ebenso eindeutig benennen, andernfalls sollte man Artikel zusammenführen.

Bin deshalb mal gespannt, ob jemand ("Sebastian schaut") einen Beleg und eine offizielle Defitition für 'Codequalität' (evtl. ohne Bindestrich besser?) findet. Evtl. wäre sinnvoll, im Artikel einen Abschnitt 'Ähnliche Begriffe' einzufügen, mit jeweils abgrenzenden Definitionen. Damit wären wir aber wieder bei Belegen vs. TF. --VÖRBY (Diskussion) 13:17, 18. Jan. 2013 (CET); ergänzt: --VÖRBY (Diskussion) 17:11, 18. Jan. 2013 (CET); klarer bei (7): --VÖRBY (Diskussion) 09:32, 20. Jan. 2013 (CET)

Meine Suche hat bisher leider nichts brauchbares ergeben, außer dass es auch in der Literatur keine eindeutige Definition von "Code-Qualität" gibt. Einige Autoren (die von Metriken) verstehen tatsächlich nur die (technische) Qualität des Sourcecodes darunter, andere gehen bis ins Design (z.B. Einsatz von Patterns), einige bis zur Architektur, und andere wider sind noch allgemeinder (d.h. inkl. Unit-Testen, SW-Entwicklungsprozesse, Projektmanagement, Best-practices, etc.).

Ich würde daher dafür plädieren den Artikel umzubenennen:

• entweder auf "Technische Softwarequalität" und dort auf die technischen Punkte der Softwarequalität (im Gegensatz zu den fachlichen/funktionalen, die beim Test geprüft werden) einzugehen. Das wären lt. ISO 9126: Effizienz (Zeitverhalten, Verbrauchsverhalten, Konformität), Wartbarkeit/Änderbarkeit (Analysierbarkeit, Modifizierbarkeit, Stabilität, Testbarkeit, Konformität), Übertragbarkeit (Anpassbarkeit, Installierbarkeit, Koexistenz, Austauschbarkeit, Konformität)
• oder mit Wartbarkeit zusammenzuführen. Da Code-Qualität immer Wartbarkeit zum Ziel hat und (zumindest) ein Teilaspekt von Wartbarkeit ist (das selbst wiederum ein Teilaspekt von Softwarequalität ist). --Sebastian.Dietrich ✉ 21:03, 18. Jan. 2013 (CET)

Guten Morgen! Deine Rechercheergebnisse decken sich also i.W. mit meiner Vermutung Nr. 6. Auch hältst du offensichtlich die jetzige Lemma-Bezeichnung für unpassend. 'Technische Codequalität' wäe mE auch nicht so richtig passend, denn da spielt die ganze Architektur und zB Security etc. mit rein. Was du zu 'technisch' schreibst, wäre dann wohl auch ein anderer 'Begriff' als das jetzt Beschriebene - das man vielleicht 'Formale CQ' nennen könnte. Was HIER und bei 'Programmierstil' beschrieben ist, betrifft ja auch deutlich mehr als die 'Wartbarkeit' - und ist m.E. in beiden Artikeln schon 'redundant': Auch wenn die beiden Lemmabezeichnungen zu anderen Wortfamilien gehören, die Artikelinhalte behandeln gleichermaßen die Aspekte zum 'WIE' des Programmierens. Hier halte ich eine Zusammenführung also für passender, unter welcher Bezeichnung auch immer. Vielleicht finden andere WP'aner noch brauchbare Quellen. Schönes Wochenende wünscht --VÖRBY (Diskussion) 11:15, 19. Jan. 2013 (CET)

• Auch der Umstand, dass für die in Frage kommenden Begriffe unterschiedliche Interpretationen gebräuchlich sind, wäre in der Einleitung jedes der fraglichen Artikel zu erwähnen.
  • Es ist hier wie schon mehrfach in der gewachsenen IT: Für die herausgebildeten Begriffe gibt es keine höhere Stelle, die präzise festlegen würde, was exakt worunter zu verstehen sei und was genau nicht.
  • Der Mainstream sollte herausgearbeitet und plausibel belegt werden; andere, weitere oder engere Verwendungen der Begriffe sollten erwähnt und querverwiesen sein. Die Sichtweise der Kollegen von der enWP ist berücksichtigenswert.
• Zwischen den Artikeln Texte hin- und herzuschieben ist noch viel zu früh. Ich sehe Code-Qualität oder wie immer verlemmat auch nicht als reinen Unteraspekt von Wartbarkeit; Code-Qualität beeinflusst unter anderem auch Sicherheit, Robustheit, Zuverlässigkeit.
• „Programmierstil“ im engeren Sinn wäre erstmal etwas, das nicht unterscheidbar ist nach Reduktion aller Whitespace-Zeichen und Kommentare.
  • Dann gibt es noch etwas wie „Programmierpraktiken“, die einen Programmierstil im weiteren Sinn eröffnen. Das geht von niederschwelligen Variationen gleichwertigen Codes bis in den Bereich der Programmierparadigmen; von (teils scheinbar überflüssiger) Klammersetzung bis zur Länge von Unterprogrammeinheiten ohne Mehrfachnutzung.
  • Weiterhin greifen schwer quantifizierbare Aspekte in die Qualität ein:
    • Namenskonvention (überhaupt vorhanden, schlüssig und dem Problem angemessen?)
    • Dokumentation (überhaupt vorhanden, automatisch aktualisierbar, verständlich?)
• Der Begriff enthält „Qualität“. Es ist eine geistige Verarmung und regelmäßig ein großer Fehler, die Frage von Qualität zu reduzieren auf bloße Quantität (Metriken), wodurch wesentliche Aspekte verloren gehen und falsche Schlussfolgerungen gezogen werden.

VG --PerfektesChaos 10:53, 20. Jan. 2013 (CET)

Aus den Diskussionen bis jetzt schließe ich (Zwischenfazit):

• Jeder Artikel sollte klare Definitionsaussagen enthalten. Das ist HIER nicht der Fall: 'subjektiv wahrgenommene', falsch (Metriken ermitteln die Qualität nicht) und mit Selbstbezug.
• Was ist 'Mainstream'? Wer legt den fest? Ich meine, da sollten wir schon auf 'Belegtes' zurückgreifen können.
• Ja, Verweise auf engere und weitere Sichtweisen sind - auch hier, wie in vielen anderen Lemmas - nützlich, bergen aber die Gefahr von TF.
• Die Abgrenzung zwischen CodeQu und PrStil haben wir noch nicht 'im Griff'. 'Schieben' ist tatsächlich noch zu früh.

Die 'wahre Erleuchtung' fehlt uns noch. --VÖRBY (Diskussion) 14:20, 20. Jan. 2013 (CET)

Hab mir deine Anmerkungen nochmal angesehen. Ich denke, es ist nicht möglich, die von dir genannten konkreten Beispiele klar dem einen (CQ) oder dem anderen (P-Stil) Ausdruck/Artikel zuzuordnen. Dies spricht für eine Zusammenführung, m.E. in das Lemma P-Stil; ergänzt um deinen Vorschlag, "... wird unterschiedlich interpretiert [bezeichnet]" in die Beschreibung aufzunehmen, und deine Beispiele zu ergänzen. Ggf mit WLS "~Code-Qualität". Das Problem der fehlenden Abgrenzung (inkl. der 'dürftigen' Definition in CQ) wäre damit aus der Welt.

Um in der Menge der Diskussionstexte die eigentliche Zielsetzung nicht aus den Augen zu verlieren, habe ich oben fett markiert und teilweise präzisiert; sorry. --VÖRBY (Diskussion) 09:48, 21. Jan. 2013 (CET)

In Diskussion:Programmierstil wurde übrigens zur Definition und zur Abgrenzung ähnlich diskutiert, offensichtlich ohne Erfolg. U.a. wurde dort 'Quelltextformatierung' als Komplement zu P-Stil vorgeschlagen. Saubere und klar abgrenzende Definitionen wurde aber auch dort nicht gefunden. --VÖRBY (Diskussion) 13:03, 21. Jan. 2013 (CET)

In der enWP existiert dieser Artikel nur als WLS auf Softwarequalität. Dort wird unterschieden zwischen den funktionalen und den strukturellen Anforderungen - die der Code erfüllen muss. CQ als Definition nur für das Strukturelle (was zudem HIER auch noch anders definiert wird) wäre demnach nicht konsistent zur enWP.--VÖRBY (Diskussion) 12:04, 22. Jan. 2013 (CET)

Vereinigen?

Habt ihr noch Einfälle dazu? Da der Artikel, zusätzlich zu schon Diskutiertem, in mehreren Details fragil (oder als TF) erscheint, setzt sich bei mir mehr und mehr die Meinung fest, die Texte mit Programmierstil zu vereinigen - soweit nicht ohnehin schon gleiche Inhalte (bzw. Bedeutungen) existieren. Ich würde dann erst einen ENTWURF erstellen. Einverstanden? --VÖRBY (Diskussion) 18:25, 23. Jan. 2013 (CET)

1. Bitte zurzeit keine Mühen in einen ENTWURF investieren.
2. Bitte bis auf Weiteres nichts mit irgendwelchen anderen Artikeln vereinigen oder auseinanderreißen oder sonstwas.
   • Und schon gar nicht irgendwas mit einem Begriff wie „Programmierstil“ vereinigen.
     • Der Begriff „Programmierstil“ ist so unklar und vieldeutig wie nur irgendwas, wurde über die Jahrzehnte und von Tausenden von wichtigen Leuten mit allen möglichen Bedeutungen verwendet.
     • Darin steckt das Wort „Stil“, und das ist eine sehr individuelle und auch Geschmacksfrage.
     • Einen derartig subjektiven Begriff mit Metriken und messbarer Qualität in Verbindung zu bringen muss schief gehen.
3. Für die nächsten Wochen und Monate wäre nicht das Verfassen von Texten, sondern das Einsammeln charakteristischer Zitate mit Fundstelle auf den diversen beteiligten Disku-Seiten angesagt.
   • Wenn sich daraus ein etwas klareres Bild herauskristallisiert, kann man anhand dieser Belege zum Ausfüllen von Artikeltexten kommen.
4. Ich habe in der letzten Woche mal in einigen Büchern diverser Jahrzehnte in deutsch und englisch rumgeblättert und alles Mögliche gefunden.

VG --PerfektesChaos 23:36, 23. Jan. 2013 (CET)

Danke für dein Feedback. Ausgangsbasis für die Diskussion war ja u.a. auch die Tatsache, dass der Artikel HIER nicht nur bezüglich seiner Bezeichnung, sondern auch in vielen anderen Details 'schräg liegt'. --VÖRBY (Diskussion) 10:03, 24. Jan. 2013 (CET)

Das bestreite ich auch nicht. Extrem unübersichtlich ist hingegen, ob

• ein Inhalt an und für sich dummes Zeug ist,
• oder nur im falschen Kontext steht. In einem anderen Artikel oder eingebettet in einen passenden Rahmen kann es hingegen sinnvoll und enzyklopädisch sein.

Da es schon ein Weilchen bis Jahre so drinsteht, müssen wir uns nicht hektisch Beine ausreißen.

• Entscheidend wäre, dass es anschließend besser ist. Dazu müssen aber alle Zielseiten ein klares Konzept haben, in die die jeweils zugehörigen Inhalte eingearbeitet werden können. Das ist aber tückisch, weil die fraglichen Begriffe in sich vieldeutig sind und von breiten Kreisen mal mit dem einen, mal dem anderen Schwerpunkt benutzt werden.

In der Ruhe liegt die Kraft. --PerfektesChaos 10:29, 24. Jan. 2013 (CET)

Zunächst möchte ich mich entschuldigen, falls ich als WPBeginner mit meinem Artikel nicht zu 100% die Anforderungen erfüllt habe. Dann möchte ich mich gegen eine Vereinigung aussprechen.

1. Ich habe mich im Rahmen eines Seminars mit dem Thema in Ansätzen beschäftigt und kam genau zu dem im Abschnitt Allgemein beschriebenen Ergebnis: Es existieren keine wissenschaftlich fundierten, objektiven Kriterien für Code-Qualität (Code-Entwicklung ist eine Kunst, keine reine Ingenieurswissenschaft).
2. Auch existiert (soweit ich recherchieren konnte) keine Definition die als Beleg herangezogen werden könnte.
3. Dennoch finde ich es aus folgenden Gründen wichtig einen eigenständigen Artikel zu behalten:
   • Der Begriff Code-Qualität ist in Lehre und Praxis gängig (was einer der Gründe ist, weshalb ich den Artikel ins Leben gerufen habe).
   • Code-Qualität vs. Software-Qualität: Im Sinne von Balzert kann Software qualitativ hochwertig sein, auch wenn die Qualität des Codes an sich miserabel ist. Solange sie ihre Anforderungen zufriedenstellend erfüllt sei alles super. Code- und Software-Qualität stehen demnach nicht direkt im Zusammenhang. Deshalb ist die einfache Weiterleitung in der enWP auch nicht korrekt. (Gegenseitige Verweise sich dennoch sinnvoll.)
   • Code-Qualität vs. Programmierstil: Der persönliche Stil eines Programmierers kann sicherlich die Qualität des Codes beeinflussen. Ja, ein guter Programmierer zeichnet sich mit Sicherheit auch dadurch aus, qualitativ hochwertigen Code zu schreiben. Dennoch sind das in meinen Augen zwei verschiedene Paar Schuhe, weshalb im Artikel auch auf Best-Practises, Entwurfsmuster und Style-Guides, als Faktoren des Programmierstils, hingewiesen wird. Im Übrigen halte ich den Programmierstil Artikel für wenig gelungen und an einigen Stellen falsch.

--Jbspeakr (Diskussion) 12:21, 27. Jan. 2013 (CET)

Jedenfalls sollten die Definitionen zu beiden Artikeln so gestaltet sein, dass man sie klar und eindeutig voneinander abgrenzen kann, wenn möglich 'belegt'. Natürlich sollten dann die Inhalte dem auch entsprechen. Der Begriff 'Qualität' (also "das Erfüllen - definierter - Anforderungen") ist für beide Artikel gleichermaßen der Überbegriff.--VÖRBY (Diskussion) 16:49, 27. Jan. 2013 (CET)

In der aktuellen iX (2/ Februar 2013) ist unter der Frage 'Wie man Quellcode-Qualität messen kann' ein Artikel von Prof. Horst Eidenberger (TU Wien) enthalten (Titel: 'Qualität nach Maß'), in dem auch kurz auf die Unterschiede zwischen Code-Qualität und Software-Qualität eingegangen wird:

• Software-Qualität beschreibt die inhaltliche Qualität (Umsetzung von Anforderungen; betrachtet wird die Anwendung als Ganzes)
• Code-Qualität beschreibt die technische Qualität (es geht "um die Software in ihrem natürlichen Aggregatzustand: den Quellcode.")

Es wird folglich auch in der Wissenschaft und Praxis zwischen beiden Begriffen unterschieden! Der Software-Qualitätsartikel müsste demnach auch reduziert/ angepasst werden. Ich werde das die Tage mal in meinem Benutzerraum in Angriff nehmen. --Jbspeakr (Diskussion) 11:03, 30. Jan. 2013 (CET)

Du zitierst Eidenberger zum Unterschied zwischen Code-Qualität und Softwarequalität. Falls das korrekt widergegeben ist, merke ich an: Wenn zB ISO/IEC 9126 "SW-Qualität" definiert, dann muss die SW alle dort definierten Kriterien erfüllen. Dass man dabei funktional und formal unterscheiden kann, steht außer Frage. 'Technisch' ist nicht korrekt bzw. unpräzise, weil Vieles in der Codierung als 'technisch' gilt oder manche gar alles als technisch bezeichnen würden. Jedenfalls basiert beides auf 'Anforderungen' (hier schon mehrfach so geschrieben!), wobei manche bestimmen, WAS das Programm (und wie) tun soll (zB zu Funktionalem, zur GUI, zur Sicherheit ...) - und andere A. bestimmen, WIE der Programmierer implementieren soll. Insofern ist die Unterscheidung mit den beiden Spiegelpunkten prinzipiell ok, nur sind die Bezeichnungen zweifelhaft: So darf der erste Teil nicht 'SWQ' (ohne zusätzliche Einschränkung) genannt werden, das ist einfach begrifflich und sprachlich eine Verletzung der ISO-Definition. Und 'Quellcodequalität' ist in IX auch schon etwas präziser als einfach nur 'Code-Qualität'.

Insofern ist der Artikel SW-Qualität mE absolut richtig positioniert, von Details vielleicht abgesehen. Es geht aber HIER iW um die inhaltliche Nicht-Abgegrenztheit von 'Code-Qualtität' und Programmierstil. Schau dir dort zB die Weblinks an, da findest du immer Aspekte zum WIE - inkl. so trivialer Dinge wie Einrückungen.--VÖRBY (Diskussion) 14:22, 30. Jan. 2013 (CET), Kleine Korr: --VÖRBY (Diskussion) 17:27, 30. Jan. 2013 (CET)

Es ist ein Unterschied, ob sich der Eidenberger-Bericht mit diesen Begriffen einfach nur in einem bestimmten Kontext befasst ODER ob deine Zitattexte dort explizit als eigenständige Definitionen vertanden werden sollen - was m.E. mindestens für SWQ nicht der Fall sein kann. --VÖRBY (Diskussion) 10:35, 31. Jan. 2013 (CET)

Es gab lange kein Feedback mehr. Ich habe deshalb heute die wichtigsten 'Problemfälle' (aus meiner Sicht) im Text korrigiert. Dazu gehört insbesondere das Entfernen 'schwammiger' Aussagen (v.a. in der Definition) sowie dass der Begriff 'Qualität' nicht vom Begriff 'Anforderungen' trennbar ist - wie bisher unter 'Allgemeines' beschrieben (~ als Erweiterung der auf Anforderungen basierenden ...). Ich halte den Ausdruck CQ nach wie vor für unbelegt und zweifelhaft und die Zusammenführung mit Programmierstil für die bessere Lösung (außer man findet klar abgrenzende Kriterien für die Definitionen), könnte aber jetzt mit dieser Redundanz 'leben'. --VÖRBY (Diskussion) 13:14, 18. Feb. 2013 (CET)

• Die heutige Änderung ist völlig in Ordnung.
• Die Materie ist verworren, insbesondere schwer nach unseren Vorstellungen in ein Lemma zu gliedern.
• Einschlägige Vorstellungen gibt es seit Jahrzehnten, aber höchst unterschiedlich. Subjektive Beurteilungen und objektiv messbare, aber womöglich irrelevante Kennzahlen fließen beide in die Qualitätsbeurteilung ein.
• Hinzu kommt, dass es keinen absoluten Maßstab gibt, sondern immer nur die Realisierung mit den Anforderungen und Vorgaben eines konkreten Projekts zu vergleichen ist.
  • Wenn man für die nächste zehn Jahre eine Infrastruktur plant und umzusetzen beginnt, muss man auf Erweiterbarkeit, Portierbarkeit, Wartbarkeit, Einarbeitungsmöglichkeit der Nachfolger achten.
  • Hat man ein Einzelprojekt, bei dem für eine spezifische Hardware in genau einer Software-Umgebung einmalig eine Lösung abzuliefern ist, dann wäre alle Mühe in eine Wiederverwendbarkeit umsonst. Wenn nicht absehbar ist, dass zukünftig sehr ähnliche Aufträge erfolgen, wäre es Ressourcenvergeudung und schlicht zu teuer, hier einen Wasserkopf an Strukturen aufzubauen. Gerade auch Prototypen, die nur zeigen sollen, dass etwas überhaupt funktionieren könnte, werden erstmal mit begrenzten Mitteln in kurzer Zeit und mit starken Grenzen entwickelt. Stellt sich dann heraus, dass dieses Produkt vielversprechend ist, kann man am Prototypen erlernen, welche Aspekte wichtig sind und was zukünftig unterstützt werden müssre, und macht dann einen weiter gefassten richtigen Entwurf und implementiert in anderen Sprachen und mit professionellerer Architektur und allen Features.
• Für „Software-Qualität“ ist die momentane Funktionalität der Maßstab; für „Code-Qualität“ die beabsichtigten zukünftigen Möglichkeiten der Wartung, Pflege, Weiterentwicklung.

Schönen Abend --PerfektesChaos 22:42, 18. Feb. 2013 (CET)

Sollte also i.W. erledigt sein. ~Fazit: Codequalität ist Teilaspekt von Softwarequalität.

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 08:51, 8. Apr. 2013 (CEST)