Tod durch Softwarefehler

Axel Berger schrieb...

War mal wieder ein Schnellschuss von mir. War aber sonst auch nicht ganz ernst gemeint. Ich halte selbst nicht viel von MISRA. Einige Regeln mögen sinnvoll sein, aber viele engen unnötig ein.

- Heinz

Heinz Saathoff schrieb:

Dem schließe ich mich an. Allein Quelltextschnipsel in Kommentaren zu verbieten gehört verboten.

Marc

Das Problem, das zu lösen versucht wird, ist durchaus real.

Gegeben eine Quelldatei zum Review oder zur Fehlersuche, 50% davon auskommentierter Code, keine weiteren Kommentare. Welcher Code davon ist tatsächlich überflüssig? Welcher ist versehentlich auskommentiert? Welcher entstammt vergangenen Experimenten, welcher ist Vorbereitung für die Zukunft?

Wir haben hier Spezis, die sowas gerne produzieren. Denen mit einem Regelwerk auf die Finger klopfen zu können ist nicht ganz verkehrt.

Nur ist es halt albern, Kommentare, die für Menschen gedacht sind, von Maschinen bewerten zu lassen.

Stefan

Mag sein, aber der Versuch der Lösung taugt nichts.

Zuerst einmal sind alle Kommentare als solche zu lesen. Wenn der echte Code also nicht will sucht man ihn ihm nach dem Fehler und überlegt nicht ob vielleicht auskommentierte Zeilen das Problem sind. Das merkt man dann schon früh genug.

Des weiteren gehört dem Programmierer, der so mit Kommentaren geizt, mal feste in den Hintern getreten. Bei uns hiess es damals, man sollte von der Menge her ähnlich viele Kommentarzeilen wie Codezeilen haben und die Kommentare sollten auch was aussagen. Und wenn es nur jeweils ein Block über jeder Funktion ist der erklärt was diese tut.

Wenn das nicht jeweils dabei steht, weder noch. Ich hab in meinem Shellscripten oft auskommentierten Code drin, meist mit einem Hinweis a la 'Activate for debugging' oder 'Old version, works but slow' usw.

Ja, denn eigentlich hat die Maschine mit den Kommentaren nur eines zu tun, nämlich beim Compilerlauf zu ignorieren.

Gerrit

Am 05.11.2013 20:57, schrieb Gerrit Heitsch:

Nö.

Ich zitiere:

"Weißt du im Moment eines Geistesblitzes, was du kommentieren musst, damit ein anderer ihn nachvoillziehen kann - oder du selber in ein paar Monaten oder Jahren?"

"Man weiß es nicht und kommentiert wie 'nen Blöden jede Zeile, um später trotzdem nicht mehr zu wissen, was das Ganze eigentlich macht." ;)

Das schon eher. Das sollten aber kaum so viele Zeilen Kommentar wie Code sein. Und noch so viel Kommentar kann keine gute Dokumentation ersetzen.

Doch, weil er dann vielleicht soviel Kommentare einbaut, wie wirklich nötig sind.

Schon, aber man kann in C und anderen Sprachen, u.a. auch PERL schönen write-only-Code schreiben. Vor allem mit regulären Ausdrücken, Ausnutzen von implizitem und Ausnutzung von Nebenwirkungen (aka 'side effects') kann man sich ganze Zeilen bauen die interessante Dinge tun, die aber in

1 Woche nicht einmal mehr der Autor versteht (und deshalb auch nicht sauber debuggen kann wenn sich eine übersehene Nebenwirkung bemerkbar macht)

Da hilft nur sauber erklären oder weniger genial sein wollen und besser lesbaren Code schreiben.

Gerrit

Womit wir wieder bei der Frage wären: Wieviel ist wirklich nötig?;)

Was heißt "write-only-Code"?

Du kannst ihn schreiben, er funktioniert dann auch, aber keiner, nicht einmal der Autor, versteht ihn am nächsten Morgen noch.

Sowas wie diese Zeile hier (in PERL):

if ($line =~/^\(\"(.*?)\"\s+(.*?)\s+\".*?\"\s+(\d+\.\d+)\s+(\d+\.\d+)\s+(\d+\.\d+)\)\s+(.*?)$/) # " { $x1 = $1; # Needed due to the pattern $x2 = $2; # matching and replace for $x3 = $3; # bad cells. $x4 = $4; $x5 = $5; $x6 = $6; [...]

(Aus einem funktionierenden Script entnommen)

Wenn du das gerade geschrieben hast verstehst du es natürlich noch und kannst Änderungen durchführen. Aber schon einen Tag später...

Gerrit

Das ist ja auch nicht unbedingt nötig, wenn's funktioniert, ist's doch ok. Vorausgesetzt, man kann absichern, dass keine "Nebenwirkungen" auftreten.

Ich hab' mir schon öfters "Trickzeilen" (ok, nicht derart verschachtelte) 'runterkopiert, bisschen umgebaut, in Funktionen eingebaut - getestet natürlich, udn entsprechend kommentiert. Dazu muss ich doch nicht wissen, "wann welches Bit wo im Speicher steht".

Ja, das ist bei solchen regulären Ausdrücken gerne das Problem. Man meint, man hat alles abgedeckt und bekommt nur einen Match mit dem was erkannt werden soll und dann findet sich leider doch noch ein Fall an den man nicht gedacht hat und darf den Ausdruck von vorne entwerfen.

Das Problem mit obigem ist, daß es so ziemlich nicht wartbar ist. Die Klammern im Ausdruck sind z.B. kein Teil des zu findenden sondern sorgen dafür, daß die für diesen Programmteil wichtigen Daten schon aus dem zu testenden String extrahiert sind wenn ein Match auftritt. Sie finden sich dann in $1 bis $6 wieder. Stichwort 'Backreferences'.

Deshalb der Ausdruck 'write-only-code'. Geschrieben, funktioniert im Rahmen der Anforderungen, nicht mehr anfassen. Bei Änderung der Anforderungen besser neu schreiben.

Gerrit

Hartmut Kraus schrieb:

Und der Müllhaufen der unwartbaren Software wächst weiter. Wir stecken noch in der Softwarekrise mittendrin, die meisten merkens nur nicht mehr.

Carsten

--
Haben unaufschiebbare Probleme erst einmal bewirkt, dass die  
hypothetische Nachvollziehbarkeit isomoph rational ist, darf angemerkt  
werden, dass die nutzungsintensiv endokrine Change-Management-Aktion  
divergierend effektiv schon lange zum Allgemeinwissen gehört, obwohl der  
charakteristisch bilinguale Gültigkeitsbereich dipolar konzentriert in  
der Bedeutungslosigkeit versinkt.

Am 07.11.2013 21:17, schrieb Gerrit Heitsch:> On 11/07/2013 09:01 PM, Hartmut Kraus wrote: >> Am 07.11.2013 19:21, schrieb Gerrit Heitsch: >>> Sowas wie diese Zeile hier (in PERL): >>> >>> if ($line >>> =~/^\(\"(.*?)\"\s+(.*?)\s+\".*?\"\s+(\d+\.\d+)\s+(\d+\.\d+)\s+(\d+\.\d+)\)\s+(.*?)$/)

Am 08.11.2013 07:40, schrieb Carsten Thumulla:

Wem sagst du das? Einem, der aus eben diesem kühlen Grunde (fast) nur noch Wartbares (und ständig Gewartetes) nutzt und sich sonst alles selber bastelt, so möglich. ;)

Ich schon. Spätestens, seit ich eben dieser Firma den Rücken gekehrt habe, weil ich diesen einmaligen Beschiss am Kunden nicht länger mitmachen wollte:

Gerrit Heitsch schrieb:

das halte ich für kein gelungenes Beispiel, denn der Ausdruck ist recht gradlinig und nicht sonderlich schwer zu verstehen. Ich hätte einen Musterstring in der Nähe erwartet.

Servus

Oliver

--
Oliver Betz, Muenchen http://oliverbetz.de/

Wenn man sich dauernd mit PERL beschäftigt, dann geht das halbwegs. Wenn nicht hat man ein Problem, die Besonderheiten der regulären Ausdrücke in PERL sind hier wichtig. Speziell das Konstrukt '.*?'.

Gerrit

Gerrit Heitsch schrieb:

[...]

ich beschäftige nicht dauernd mit Perl, greife bei Bedarf halt auf meine Notizen zurück.

BTW: PCRE kann man auch dann effizienzsteigernd einsetzen, wenn man nicht PERL etc. programmiert - jeder gute Texteditor unterstützt PCRE für Suchen und Ersetzen.

Das mit der "greediness" sollte man halt mal gehört haben.

Und es gibt gute Hilfsmittel für PCRE.

Servus

Oliver

--
Oliver Betz, Muenchen http://oliverbetz.de/

Hallo Hartmut,

Du schriebst am Wed, 06 Nov 2013 17:44:49 +0100:

t, mal

Doch. Zur Bekräftigung schau' Dir mal den Linux-Kernel-Code an.

Deswegen sollst Du ja nicht beschreiben, _wie_ der Code arbeitet, sondern kommentieren, _was_ er tut.

Kommentar _ist_ Dokumentation, und zwar Dokumentation für den Programmierer, dem, der das Original schrieb für später, oder ein em anderen, der daran mal weiterarbeitet.

Ganz besonders dringend nötig sind Kommentare allerdings oft bei C-Programmen, deren Schreiber ja gerne eine extreme Schreibfaulheit als Leistungsmerkmal kultivieren. Das zeigt sich dann nicht nur an den sowieso schon minimal gehaltenen Strukturmarkierungen, sondern auch an den Bezeichnern, die dann gerne bis weit unter die Unkenntlichkeit abgekür zt sind. Namen wie "ptr" oder "buf" sind da noch herausragende Beispiele f r Offensichtlichkeit. Oder es wird irgend ein Schreckenswerk von Codierungsregeln benutzt, nach denen jeder Bezeichner mit einer ellenlangen Typenplanungskonstruktion einzuleiten ist (und die nach der erfolgreichen Inbetriebnahme der Software nur noch marginal mit dem zu tun hat, was sie zu bedeuten vorgibt), die dann gerne mal dreimal länger als der eigentliche Name ausfällt, der dann wieder nach den "normalen" Vorlieben abgekürzt angeklebt wird.

--
--  
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung 
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) 
----------------------------------------------------------- 
Mit freundlichen Grüßen, S. Schicktanz 
-----------------------------------------------------------

Hallo Carsten,

Du schriebst am Fri, 08 Nov 2013 07:40:48 +0100:

stecken

Optimist.

--

-- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)

----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz

-----------------------------------------------------------

Am 10.11.2013 19:37, schrieb Sieghard Schicktanz:

Naja, ganz soooo schlimm ist es noch nicht. Ich bin doch aus dem Geschäft 'raus. Aber wartet's nur ab, bis meine Machwerke ihre Auswirkungen in meiner Kiste zeigen. ;)

Am 10.11.2013 19:33, schrieb Sieghard Schicktanz:

Wozu? Bei mir funktionieren die Kernels zur vollsten Zufriedenheit, sehe also keinen Grund, dadrin 'rumzuprogrammieren. Nicht mal selber compilieren - hab' ich einmal, gemacht, bringt nicht wirklich was.

Kommt auf's selbe 'raus.

Meine Güte, ich hab' mal an einem Teil dieser Software mitgearbeitet:

(In Visual Basic, streng objektorientiert.) Die Programmierrichtlinien dort waren vorbildlich, eben genau so, wie's hier verlangt wird. "Schreib' deinen Code übersichtlich, halt' dich an unsere Konventionen, kommentiere ordentlich, aber nicht jede Zeile, sondern im Kopf jeder Prozedur / Funktion: Aufgabe, Übergabeparameter, Rückgabewert.

Aber die Doku dazu waren bei dem damaligen Teil auch noch mal ein paar hundert Seiten. Ohne die hätte ich gar nicht verstanden, wie sie das eigentlich gemacht haben.

Alles kein Grund, alles mit Kommentaren zuzumüllen. Also für die Schreibfaulheit sofort büßen zu müssen. ;)