Ich kann mir nicht vorstellen, dass diese Tools wirklich "echte" Bugs finden. Mit echt meine ich Bugs die man nicht selber nach kurzer durchsicht schon sieht. Es wird so was sein (oder ein wenig besser) wie lint oder aehnliche tools. Evtl. gepaart mit code-metrics (die ebenfalls SEHR problematisch) sind.
Schon Alan Turing hat an seiner Turing Machine klar gemacht, dass kein Algorithmus existieren *kann* der einem sagt, ob ein zu ueberpruefendes Programm in endlicher Zeit laufen wird, oder nicht. Das sog "halting problem"
http://en2.wikipedia.org/wiki/Halting_problem
Soll aber nur ein bespiel sein. Wass ich sagen will: Selbst wenn nach einem check mit einem SW Tool der Quellcode ein 1+ bekommt, sagt das eher wenig ueber die Qualitaet, weil einfach viele Dinge nicht berueksichtigt werden _koennen_.
"Die anderen 8 Fehler wurden als Fehlalarme eingestuft" sagt ja schon alles.
Na, es wurden immerhin mehr Probleme und Problemchen entdeckt als Fehlalarme geschmissen.
Übrigens kann man "echte Bugs" durch eine genaue Programmverifikation durchaus finden und das auch automatisieren. Lernt man als Informatiker im Grundstudium.
Nun, bei uns zumindest haben wir durchaus von dem guten Alan gehört. :-)
Aber es gibt ja mehrere Stufen der "Korrektheit". Ein Programm kann niemals alle eventuellen Fehler finden, das ist denke ich mal klar. Aber ein Programm kann die partielle Korrektheit nachweisen, also ob ein Programm immer dann wenn es etwas sinnvolles tut, auch das richtige tut. Die andere Richtung würde den Nachweis verlangen, dass ein Programm mit allen eventuellen Eingabewerten richtig umgehen kann. Und eben das halte ich für sehr schwierig in Software zu implementieren.
Die Standard-C-Fehler kann natürlich ein Programm entdecken, der GCC bringt ja auch Warnungen wenn eine Variable nicht initialisiert wird bevor man sie verwendet. Oder NULL-Pointer und sowas. Eben jede Fehler, die man nur in C(++) kennt. :-)
ac: Das Wortproblem fuer Typ-0-Grammatiken ist unentscheidbar. Allerdings gibt es durchaus vernuenftige Einschraenkungen, die dann z.B. zu den Typ-1-Grammatiken fuehren, da ist dann das Wortproblem (durch Linear Beschraenkte TM'en) entscheidbar. Von der Seite der Theoretischen Informatik muss man dazu sagen, dass zur Programmverifikation man sich haeufig auf Grammatiken beschraenken kann, bei denen das Halteproblem entscheidbar ist. Deswegen funktioniert das auch (theoretisch) recht gut.
Von Gunter Ohrner am Do, 18. Dezember 2003 um 11:25 #
Doch. Vollautomatische Programmverifikation kann niemald vollständig und korrekt sein, aber korrekt an sich auf jeden Fall und mehr oder weniger "beliebig" gut. Was meinst du, warum sich ganz Forschergruppen mit der automatischen Programmverifikation beschäftigen - bestimmt nicht weil alle sicher sind, dass der ganze Aufwand ohnehin nichts bringt. Immerhin kann das System einen riesengroßen Teil der Standardfälle abdecken, und nur ganz selten muss es mal den Benutzer "um Rat fragen", bevor es weiterrechnen kann.
>>>>Ich kann mir nicht vorstellen, dass diese Tools wirklich "echte" Bugs finden. Mit echt meine ich Bugs die man nicht selber nach kurzer durchsicht schon sieht.
In aller früh muss ich schon lachen. Wie war das "Bugs die man man nicht nach kurzer Durchsicht schon sieht", dann sag mir doch mal wie du mal schnelle 216000 Zeilen Code durchsiehst. Es wurden aber 15 Bugs gefunden, was die MySQL Entwickler bestätigten:
"Die 21 vermeintlichen Probleme setzen sich aus 3 Speicherlöchern, 15 möglichen NULL-Pointer-Zugriffen und 3 uninitialisierten Variablen zusammen. Die Fehler wurden an die MySQL-Entwickler gemeldet, die 13 davon bestätigten und unmittelbar korrigierten. Die anderen 8 Fehler wurden als Fehlalarme eingestuft."
Hauptsache man hat halt wieder nen klugen Spruch losgelassen gelle
Du musstes lachen, weil du mich nicht verstanden hast (oder nicht verstehen wolltest -- vielleicht selber "nen klugen Spruch" ablassen?)
Mit "nach kurzer Durchsicht" waren natuerlich nicht 216k LOC durchsehen gemeint, sondern ich meinte dass die Bugs leicht gefunden worden waeren wenn man sich nur den Code vorgenommen haette der ihn enthaelt. Das man das vorher nicht weiss ist mir schon klar. Das war aber nicht der Punkt. Der Punkt war, dass dieses Tool wohl nicht viel intelligenter ist (bzw. sein kann) als ein Programmierer.
Ausserdem hast du nicht aufgepasst es waren 13 Bugs. Das hasst du selber gepostet: "an die MySQL-Entwickler gemeldet, die 13 davon bestätigten".
Das bedeutet aber nicht, dass MySql jetzt bug frei ist, oder? Da sind wir uns einig, oder?
Mögen ja nicht wirklich Grips haben diese Tools. Aber was soll der Geiz? Warum sollte man so Tools nicht dennoch nutzen? Sie helfen immerhin etwas. Das ist doch schon viel wert. 13 gefundene Bugs sind doch besser, als wenn die nicht gefunden worden wären. Offensichtlich gibt es weder bei den Closed-Source noch Open-Source-Entwicklungen genügend Programmierer, die sich den Code denn auch wirklich mal vornehmen. Da ist es dann immer noch besser man nutzt dann wenigstens Tools. Dass die Tools dabei noch lange nicht intelligenter sind als Programmierer ist klar. Und dass der Einsatz von diesen Tools mitnichten bedeutet, dass nun alles ganz toll und fehlerfrei ist, sagen ja sogar die Durchführer dieses Tests.
Was m.E. die einzige Gefahr dabei ist: Dass durch den Einsatz solcher Tools am Ende die Entwickler vielleicht sogar noch durchsichtsfauler werden und sich in einer falschen Sicherheit wiegen. Was allerdings dann im Widerspruch zur Aussage stünde dass die intelligent sind...
Über Code-Qualität sagt das ganze aber m.E. dennoch nichts bzw. allenfalls wenig aus. Denn Code-Qualität hat zwar natürlich auch eine Menge mit Fehlerarmut zu tun, betrifft aber auch Dinge, wie Wartbarkeit, Lesbarkeit etc. Und das dürfte automatisch noch viel weniger zu überprüfen sein.
"Über Code-Qualität sagt das ganze aber m.E. dennoch nichts ..." Genau das war mein punkt. (Neben der tatsache natuerlich, dass bestimmte Bugs nicht gefunden werden _koennen_).
Neben "Wartbarkeit, Lesbarkeit" waere mir vor allem noch Design eingefallen. Denn /das/ entscheided ebenfalls massgeblich ueber die Fehleranfaelligkeit.
Es geht nicht um den Geiz. Es geht darum, dass man mit so einem einfachen Tool nicht eine so komplexe SW bewerten darf. Der Artikel suggeriert, dass der MySql code gut ist weil das Tool wenig Fehler gefunden hat. Und diese Schlussfolgerung ist fragwuerdig (at least).
Das war der Grund fuer mein erstes Posting. Dein Posting hat es im Grunde bestaetigt.
Du hast sein Posting wohl nicht ganz durch gelesen. Am Ende sagt er doch ganz klar das ein Qualitätsvergleich wenig Sinn macht.
Solche Fehlersuchtools gehören eigentlich sowieso gleich in den Compiler, bzw. die Programiersprache sollte viele Fehler erst garnicht zulassen.
Ein Tool schafft es aber nie zwischen einem gewolltem Feature und einem Bug zu unterscheiden. Selbst menschliche Programmierer bei M$ haben Probleme damit.
1. Du hast recht. Die Grundaussage der Studie ist extrem zweifelhaft. Ein vollautomatisches Tool über den Code zu jagen, sagt nichts nennenswertes über den Code aus. Soweit stimme ich Dir zu.
2. Dennoch finde ich den Einsatz von solchen Tools zur Unterstützung der Entwickler ganz gut. Wenn die was finden, ist es jedenfalls okay so Tools einzusetzen. Man muss nur deren Grenzen kennen... Ich hatte in Deine Postings reininterpretiert (so gesagt hast Du es zugegebenermassen nirgends), dass Du auch gleich den Einsatz solcher Tools von vornherein falsch finden würdest. Da würde ich Dir, wenn denn meine Interpretation richtig war, nicht in jedem Fall zustimmen. Ansonsten hab ich da halt einfach was ruminterpretiert, was gar nicht da war ;-)
Anyway: Mir scheint, dass wir uns im Großen und Ganzen doch weitestgehend einig sind.
> Was m.E. die einzige Gefahr dabei ist: Dass durch den Einsatz solcher Tools am Ende die > Entwickler vielleicht sogar noch durchsichtsfauler werden und sich in einer falschen > Sicherheit wiegen. Was allerdings dann im Widerspruch zur Aussage stünde dass die > intelligent sind...
Es gibt wohl Studien, das Sicherheitsgurte, Helme oder sonstige Sicherheitselemente nicht wirklich was bringen. In dem Masse wie die Überlebenschance dadurch steigt, soll auch die Wahrscheinlichkeit steigen, durch das erhöhte Sicherheitsgefühlt in einen Unfall verwickelt zu werden.
Solche Studien sind sehr mit Vorsicht zu genießen. Du kannst ja Dinge wie Sicherheitsgefühl und Risikobereitschaft nicht direkt messen und auch keine Experimente dazu veranstalten, sondern nur die natürlich auftretenden Fälle. Und welche Schlussfolgerungen du daraus ziehst, hat auch was damit zu tun, was deiner Meinung nach rauskommen sollte.
Also es mag nicht garantierne können, dass die eine oder die andere Software besser ist, aber so ein Tool kann definitiv eine Tendenz aufzeigen. Wenn MySQL nur 23 Fehler enthält (welche von dem Programm entdeckt werden konnten) und andere Software wesentlich mehr, dann liegt der Schluss nahe (nicht bewiesen), dass insgesamt bei MySQL weniger Fehler entstehen, da zumindest in dem Bereich den das Tool abdeckt weniger entstanden sind. Das lässt auf mehr Gründlichkeit bei der Programmierung/Kontrolle schliessen. Gut, Wartbarkeit, und Lesbarkaeit usw. kann so ein Tool natürlich nicht überprüfen, aber ich kaufe auch lieber ein Auto, bei dem nur 3 Fehler gefunden worden sind, als eines mit 3500 Fehlern (natuerlich alle aus dem gleichen Bereich, denn wenn einer der 3 Fehler ist: Bremsen kaputt oder Motor im Arsch ...)
Tja weil es eben nicht so einfach ist, wie man bei manchen selbstgefälligem Schreiberling meinen könnte, z.B. Speicherlöcher findet man eben nicht einfach durch durchsehen des Codes, ohne gute Tools geht da selten was.
da ich nicht weiss, ob "selbstgefälligem Schreiberling" jetzt mich meint oder doch nicht anworte ich mal.
Also, Mem leaks findet man aber mit tools die GANZ ANDERS arbeiten. Die schaun sich nicht den code statisch an sondern das executable wird ausgefuehrt und man checkt den heap und zum schluss schaut man was nicht ge'free'd wurde.
... zumindest im Übertragenen Sinne. Die Fehler die mit solchen Werkzeugen gefunden werden, könnte man auch von Hand finden. Könnte - wenn man sich die Mühe machen würde. Andererseits ist jeder Fehler der auf diese Weise gefunden und beseitigt wurde ein potentielles Problem weniger.
Um bei der Rechtschreibung zu bleiben. Eine korrekte Rechtschreibung sagt nichts über die Qualität des Textinhalts aus. Selbst mit korrekter Grammatik ist es möglich sinnleere Texte zu verfassen.
In sofern würde ich von einem solchen Werkzeug nicht mehr aber auch nicht weniger erwarten als in der Meldung erwähnt ist.
Timmy - der hofft das dieser Text nicht selbstbezüglich ist.
Leider kann es kein Tool geben, das logische Fehler findet. Dann würde sich nämlich rausstellen das freie Softwar nämlich fiele logische Fehler hätte. Vielleicht mehr als kommerzieller Software ( obwohl frei und kommerzielle sich nicht ausschlissen). Denn es gehen immernoch zu viele freie Programm von der falschen Annahme aus, das ihre Dokumentation gelesen würde
> Leider kann es kein Tool geben, das logische Fehler findet.
Das gilt zwar im allgemeinen, mit vernünftigen Einschränkungen kann man aber schon manche Dinge automatisch verifizieren.
> Dann würde sich nämlich rausstellen das freie Softwar nämlich fiele logische Fehler hätte. [...] > Denn es gehen immernoch zu viele freie Programm von der falschen Annahme aus, das ihre Dokumentation gelesen würde
Häh? Was will Du mir mitteilen, rübzahl? Was hat Dokumentation mit logischen Programm-Fehlern zu tun? Warum sollten Programme von irgendetwas "ausgehen"?
Ich meinte das Gerede von diesem 'TBO', nicht den Versuch ein solches Programm zu verwirklichen. Mir ist allerdings unklar, wie ein Programm sein soll (über eine KI-Maschine?) das logische Fehler findet; die gehören doch mit zu den verstecktesten Fehlern überhaupt.
Von UliTheGrey am Mi, 17. Dezember 2003 um 22:04 #
Die Aussage, daß MySQL besser ist als andere SW weil die Fehlerhäufigkeit der (automatisch) erkennbaren Fehler mit der Gesamtfehlerhäufigkeit korreliert ist fragwürdig.
Ich würde sagen, ein Programm, das viele (automatisch) erkennbare Fehler (eF) hat hat wahrscheinlich auch noch viele unerkannte Fehler (uF), d.h. #eF ist proportional zu #uF für große #eF.
Nun haben wir den Fall, daß nur wenige (automatisch) erkennbare Fehler vorhanden waren - was kann man daraus schließen ? Die geringe Zahl an eF könnte eben daran liegen, daß diese durch die bereits verwendeten Tools oder die (im Vergleich zu anderen Entwicklungsverfahren) größere Anzahl an Programmierern oder durch entsprechend viele aufgetretene und leicht erkennbare Laufzeit-Bugs (Memory Leaks und Nullpointer sind meist relativ leicht erkennbar) auch von Anwenderseite erkannt und im Anschluß behoben worden.
Software-Qualität ist m.E. nicht statisch/automatisch vom Quellcode her zu bewerten - wenn der nicht gut aussieht ist wahrscheinlich der Rest auch nicht gut. Man kann aber auch sehr sauberen Code schreiben (oder generieren), der absolut daneben liegt.
Letzlich muß man den gesamten Entwicklungsprozeß und das dynamische Verhalten des Systems (Anwender, Entwickler, Produkt) analysieren um eine Vorstellung von der Qualität oder gar eine Vergleichbarkeit derselben zu ermitteln.
Wenn man davon ausgeht das alle großen Programmierprojekte solche automatischen Fehlersuchprogramme benutzen wie die in der Studie benutzten, so fällt die Studie für das Projekt am besten aus, das ein ähnlicheres Fehlersuchprogramm als die Konkurenz benutzt.
Beispiel: Nach Behebung der Fehler bei Trolltech kann man den Test widerholen. Ergebniss: Trolltech hat nur noch 8 Fehlermeldungen, die alle Fehlalarme sind. Wenn Trolltec das im Test benutzte Fehlersuchprogramm benutz hätte, hätten sie weit besser abgeschnitten.
Fazit: Die Studie ist nicht aussagekräftig ohne berücksichtigung der Entwicklungs- und Fehlersuchprogramme
Mit echt meine ich Bugs die man nicht selber nach kurzer durchsicht schon sieht.
Es wird so was sein (oder ein wenig besser) wie lint oder aehnliche tools.
Evtl. gepaart mit code-metrics (die ebenfalls SEHR problematisch) sind.
Schon Alan Turing hat an seiner Turing Machine klar gemacht, dass kein Algorithmus
existieren *kann* der einem sagt, ob ein zu ueberpruefendes Programm in endlicher
Zeit laufen wird, oder nicht. Das sog "halting problem"
http://en2.wikipedia.org/wiki/Halting_problem
Soll aber nur ein bespiel sein. Wass ich sagen will: Selbst wenn nach einem
check mit einem SW Tool der Quellcode ein 1+ bekommt, sagt das eher wenig
ueber die Qualitaet, weil einfach viele Dinge nicht berueksichtigt werden _koennen_.
"Die anderen 8 Fehler wurden als Fehlalarme eingestuft" sagt ja schon alles.
Happy coding,
AC
Übrigens kann man "echte Bugs" durch eine genaue Programmverifikation durchaus finden und das auch automatisieren. Lernt man als Informatiker im Grundstudium.
screne
Dann wuerd ich sagen hat dein Lehrstuhl den ACM Turing Award verdient
Hoert man im Grundstudium neuerdings nichts mehr von Alan Turing?
;-)
AC
Aber es gibt ja mehrere Stufen der "Korrektheit". Ein Programm kann niemals alle eventuellen Fehler finden, das ist denke ich mal klar.
Aber ein Programm kann die partielle Korrektheit nachweisen, also ob ein Programm immer dann wenn es etwas sinnvolles tut, auch das richtige tut. Die andere Richtung würde den Nachweis verlangen, dass ein Programm mit allen eventuellen Eingabewerten richtig umgehen kann. Und eben das halte ich für sehr schwierig in Software zu implementieren.
Die Standard-C-Fehler kann natürlich ein Programm entdecken, der GCC bringt ja auch Warnungen wenn eine Variable nicht initialisiert wird bevor man sie verwendet. Oder NULL-Pointer und sowas. Eben jede Fehler, die man nur in C(++) kennt. :-)
cu, Bernd
Schau dir einfach mal den Link an:
http://en2.wikipedia.org/wiki/Halting_problem
AC
Das Wortproblem fuer Typ-0-Grammatiken ist unentscheidbar. Allerdings gibt es durchaus vernuenftige Einschraenkungen, die dann z.B. zu den Typ-1-Grammatiken fuehren, da ist dann das Wortproblem (durch Linear Beschraenkte TM'en) entscheidbar. Von der Seite der Theoretischen Informatik muss man dazu sagen, dass zur Programmverifikation man sich haeufig auf Grammatiken beschraenken kann, bei denen das Halteproblem entscheidbar ist. Deswegen funktioniert das auch (theoretisch) recht gut.
;=)
Grüße,
Gunter Ohrner
Mit echt meine ich Bugs die man nicht selber nach kurzer durchsicht schon sieht.
In aller früh muss ich schon lachen. Wie war das "Bugs die man man nicht nach kurzer Durchsicht schon sieht", dann sag mir doch mal wie du mal schnelle 216000 Zeilen Code durchsiehst. Es wurden aber 15 Bugs gefunden, was die MySQL Entwickler bestätigten:
"Die 21 vermeintlichen Probleme setzen sich aus 3 Speicherlöchern, 15 möglichen NULL-Pointer-Zugriffen und 3 uninitialisierten Variablen zusammen. Die Fehler wurden an die MySQL-Entwickler gemeldet, die 13 davon bestätigten und unmittelbar korrigierten. Die anderen 8 Fehler wurden als Fehlalarme eingestuft."
Hauptsache man hat halt wieder nen klugen Spruch losgelassen gelle
wolltest -- vielleicht selber "nen klugen Spruch" ablassen?)
Mit "nach kurzer Durchsicht" waren natuerlich nicht 216k LOC durchsehen gemeint,
sondern ich meinte dass die Bugs leicht gefunden worden waeren wenn man sich
nur den Code vorgenommen haette der ihn enthaelt. Das man das vorher nicht weiss
ist mir schon klar. Das war aber nicht der Punkt. Der Punkt war, dass dieses
Tool wohl nicht viel intelligenter ist (bzw. sein kann) als ein Programmierer.
Ausserdem hast du nicht aufgepasst es waren 13 Bugs. Das hasst du selber
gepostet: "an die MySQL-Entwickler gemeldet, die 13 davon bestätigten".
Das bedeutet aber nicht, dass MySql jetzt bug frei ist, oder? Da
sind wir uns einig, oder?
AC
Was m.E. die einzige Gefahr dabei ist: Dass durch den Einsatz solcher Tools am Ende die Entwickler vielleicht sogar noch durchsichtsfauler werden und sich in einer falschen Sicherheit wiegen. Was allerdings dann im Widerspruch zur Aussage stünde dass die intelligent sind...
Über Code-Qualität sagt das ganze aber m.E. dennoch nichts bzw. allenfalls wenig aus. Denn Code-Qualität hat zwar natürlich auch eine Menge mit Fehlerarmut zu tun, betrifft aber auch Dinge, wie Wartbarkeit, Lesbarkeit etc. Und das dürfte automatisch noch viel weniger zu überprüfen sein.
"Über Code-Qualität sagt das ganze aber m.E. dennoch nichts ..."
Genau das war mein punkt. (Neben der tatsache natuerlich, dass bestimmte
Bugs nicht gefunden werden _koennen_).
Neben "Wartbarkeit, Lesbarkeit" waere mir vor allem noch Design eingefallen.
Denn /das/ entscheided ebenfalls massgeblich ueber die Fehleranfaelligkeit.
AC
Es geht nicht um den Geiz. Es geht darum, dass man mit so einem einfachen
Tool nicht eine so komplexe SW bewerten darf. Der Artikel suggeriert,
dass der MySql code gut ist weil das Tool wenig Fehler gefunden hat.
Und diese Schlussfolgerung ist fragwuerdig (at least).
Das war der Grund fuer mein erstes Posting. Dein Posting hat es im Grunde
bestaetigt.
Am Ende sagt er doch ganz klar das ein Qualitätsvergleich wenig Sinn macht.
Solche Fehlersuchtools gehören eigentlich sowieso gleich in den Compiler, bzw. die Programiersprache sollte viele Fehler erst garnicht zulassen.
Ein Tool schafft es aber nie zwischen einem gewolltem Feature und einem Bug zu unterscheiden.
Selbst menschliche Programmierer bei M$ haben Probleme damit.
Gruss quarks.
1. Du hast recht. Die Grundaussage der Studie ist extrem zweifelhaft. Ein vollautomatisches Tool über den Code zu jagen, sagt nichts nennenswertes über den Code aus. Soweit stimme ich Dir zu.
2. Dennoch finde ich den Einsatz von solchen Tools zur Unterstützung der Entwickler ganz gut. Wenn die was finden, ist es jedenfalls okay so Tools einzusetzen. Man muss nur deren Grenzen kennen... Ich hatte in Deine Postings reininterpretiert (so gesagt hast Du es zugegebenermassen nirgends), dass Du auch gleich den Einsatz solcher Tools von vornherein falsch finden würdest. Da würde ich Dir, wenn denn meine Interpretation richtig war, nicht in jedem Fall zustimmen. Ansonsten hab ich da halt einfach was ruminterpretiert, was gar nicht da war ;-)
Anyway: Mir scheint, dass wir uns im Großen und Ganzen doch weitestgehend einig sind.
> Was m.E. die einzige Gefahr dabei ist: Dass durch den Einsatz solcher Tools am Ende die
> Entwickler vielleicht sogar noch durchsichtsfauler werden und sich in einer falschen
> Sicherheit wiegen. Was allerdings dann im Widerspruch zur Aussage stünde dass die
> intelligent sind...
Es gibt wohl Studien, das Sicherheitsgurte, Helme oder sonstige Sicherheitselemente nicht wirklich was bringen. In dem Masse wie die Überlebenschance dadurch steigt, soll auch die Wahrscheinlichkeit steigen, durch das erhöhte Sicherheitsgefühlt in einen Unfall verwickelt zu werden.
Gruss quarks.
> Mit echt meine ich Bugs die man nicht selber nach kurzer durchsicht schon sieht.
Hm, das Tool hat aber diverse Bugs in Mysql gefunden. Warum haben die Mysql Entwickler die nicht "nach kurzer durchsicht" selbst gefunden?
anworte ich mal.
Also, Mem leaks findet man aber mit tools die GANZ ANDERS arbeiten. Die
schaun sich nicht den code statisch an sondern das executable wird ausgefuehrt
und man checkt den heap und zum schluss schaut man was nicht ge'free'd wurde.
Was willst du also sagen?
AC
Die Fehler die mit solchen Werkzeugen gefunden werden, könnte man auch von Hand finden.
Könnte - wenn man sich die Mühe machen würde.
Andererseits ist jeder Fehler der auf diese Weise gefunden und beseitigt wurde ein potentielles Problem weniger.
Um bei der Rechtschreibung zu bleiben.
Eine korrekte Rechtschreibung sagt nichts über die Qualität des Textinhalts aus.
Selbst mit korrekter Grammatik ist es möglich sinnleere Texte zu verfassen.
In sofern würde ich von einem solchen Werkzeug nicht mehr aber auch nicht weniger erwarten als in der Meldung erwähnt ist.
Timmy - der hofft das dieser Text nicht selbstbezüglich ist.
findet. Dann würde sich nämlich rausstellen das freie
Softwar nämlich fiele logische Fehler hätte. Vielleicht
mehr als kommerzieller Software ( obwohl frei und
kommerzielle sich nicht ausschlissen). Denn es gehen
immernoch zu viele freie Programm von der falschen
Annahme aus, das ihre Dokumentation gelesen würde
Das gilt zwar im allgemeinen, mit vernünftigen Einschränkungen kann man aber schon manche Dinge automatisch verifizieren.
> Dann würde sich nämlich rausstellen das freie Softwar nämlich fiele logische Fehler hätte. [...]
> Denn es gehen immernoch zu viele freie Programm von der falschen Annahme aus, das ihre Dokumentation gelesen würde
Häh? Was will Du mir mitteilen, rübzahl?
Was hat Dokumentation mit logischen Programm-Fehlern zu tun? Warum sollten Programme von irgendetwas "ausgehen"?
Aber wget z.B ist nicht "Intuitiv". Aber das sollte es auch nicht sein. Für "man wget" braucht es auch keine intuition.
Hä, hä? Dann erklär uns doch mal, wie ein Tool aussehen sollte das logische Fehler verifiziert.
Das ist doch Kiddygesülze!
Grüße,
Gunter
Mir ist allerdings unklar, wie ein Programm sein soll (über eine KI-Maschine?) das logische Fehler findet; die gehören doch mit zu den verstecktesten Fehlern überhaupt.
Jedenfalls nicht so.
Man kann Performance, Abstürze ,... messen...
Wenn Bugs zu finden sind, dann werden sie gefixed, wenn keine zu finden sind, heißt das nicht, da sind keine.
Und OSS steht zu ihren Bugs, wo gegen Kommerzielle Bugs tot geschwiegen werden.
Ich würde sagen, ein Programm, das viele (automatisch) erkennbare Fehler (eF) hat hat wahrscheinlich auch noch viele unerkannte Fehler (uF), d.h. #eF ist proportional zu #uF für große #eF.
Nun haben wir den Fall, daß nur wenige (automatisch) erkennbare Fehler vorhanden waren - was kann man daraus schließen ? Die geringe Zahl an eF könnte eben daran liegen, daß diese durch die bereits verwendeten Tools oder die (im Vergleich zu anderen Entwicklungsverfahren) größere Anzahl an Programmierern oder durch entsprechend viele aufgetretene und leicht erkennbare Laufzeit-Bugs (Memory Leaks und Nullpointer sind meist relativ leicht erkennbar) auch von Anwenderseite erkannt und im Anschluß behoben worden.
Software-Qualität ist m.E. nicht statisch/automatisch vom Quellcode her zu bewerten - wenn der nicht gut aussieht ist wahrscheinlich der Rest auch nicht gut. Man kann aber auch sehr sauberen Code schreiben (oder generieren), der absolut daneben liegt.
Letzlich muß man den gesamten Entwicklungsprozeß und das dynamische Verhalten des Systems (Anwender, Entwickler, Produkt) analysieren um eine Vorstellung von der Qualität oder gar eine Vergleichbarkeit derselben zu ermitteln.
Beispiel:
Nach Behebung der Fehler bei Trolltech kann man den Test widerholen.
Ergebniss: Trolltech hat nur noch 8 Fehlermeldungen, die alle Fehlalarme sind.
Wenn Trolltec das im Test benutzte Fehlersuchprogramm benutz hätte, hätten sie weit besser abgeschnitten.
Fazit:
Die Studie ist nicht aussagekräftig ohne berücksichtigung der Entwicklungs- und Fehlersuchprogramme
Gruß
Mark