Tod durch Softwarefehler

[Heinz Saathoff]

Axel Berger schrieb...

Heinz Saathoff wrote on Mon, 13-11-04 13:14:
Warum nicht alle Kommentare in ROT-13 schreiben?

Weil das, wie der Name schon andeutet, nur Buchstaben tauscht und keine
Satzzeichen und damit den Zweck völlig verfehlt.

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

 

[Marc Santhoff]

Heinz Saathoff <newshsaat@arcor.de> schrieb:

Ich halte selbst nicht viel von MISRA. Einige Regeln mögen sinnvoll
sein, aber viele engen unnötig ein.

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

Marc

 

[Stefan Reuther]

Gerrit Heitsch wrote:

On 11/01/2013 08:41 PM, Hartmut Kraus wrote:
Am 01.11.2013 20:04, schrieb Stefan Reuther:
Aber sie verbieten immerhin, Code auszukommentieren,

Interessant und durchaus sinnvoll.

Sehe ich anders. Kommentare sollen den Code erklären und manchmal geht
das eben mit einem kurzen Stück Code der eine Verwendung erklärt besser
als mit 5 Seiten Text.

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

 

[Gerrit Heitsch]

On 11/05/2013 08:39 PM, Stefan Reuther wrote:

Gerrit Heitsch wrote:
On 11/01/2013 08:41 PM, Hartmut Kraus wrote:
Am 01.11.2013 20:04, schrieb Stefan Reuther:
Aber sie verbieten immerhin, Code auszukommentieren,

Interessant und durchaus sinnvoll.

Sehe ich anders. Kommentare sollen den Code erklären und manchmal geht
das eben mit einem kurzen Stück Code der eine Verwendung erklärt besser
als mit 5 Seiten Text.

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

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

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?

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.

Welcher entstammt vergangenen Experimenten, welcher ist Vorbereitung für
die Zukunft?

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.

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

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

Gerrit

 

[Hartmut Kraus]

Am 05.11.2013 20:57, schrieb Gerrit Heitsch:

Des weiteren gehört dem Programmierer, der so mit Kommentaren geizt, mal
feste in den Hintern getreten.
Nö.

Bei uns hiess es damals, man sollte von
der Menge her ähnlich viele Kommentarzeilen wie Codezeilen haben
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."

Und wenn es nur jeweils ein Block
über jeder Funktion ist der erklärt was diese tut.

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

 

[Gerrit Heitsch]

On 11/06/2013 05:44 PM, Hartmut Kraus wrote:

Am 05.11.2013 20:57, schrieb Gerrit Heitsch:
Des weiteren gehört dem Programmierer, der so mit Kommentaren geizt, mal
feste in den Hintern getreten.
Nö.

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

Bei uns hiess es damals, man sollte von
der Menge her ähnlich viele Kommentarzeilen wie Codezeilen haben
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."

Und wenn es nur jeweils ein Block
über jeder Funktion ist der erklärt was diese tut.
Das schon eher. Das sollten aber kaum so viele Zeilen Kommentar wie Code
sein. Und noch so viel Kommentar kann keine gute Dokumentation ersetzen.

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

 

[Hartmut Kraus]

Am 06.11.2013 20:31, schrieb Gerrit Heitsch:

On 11/06/2013 05:44 PM, Hartmut Kraus wrote:
Am 05.11.2013 20:57, schrieb Gerrit Heitsch:
Des weiteren gehört dem Programmierer, der so mit Kommentaren geizt, mal
feste in den Hintern getreten.
Nö.

Doch, weil er dann vielleicht soviel Kommentare einbaut, wie wirklich
nötig sind.
Womit wir wieder bei der Frage wären: Wieviel ist wirklich nötig?

Bei uns hiess es damals, man sollte von
der Menge her ähnlich viele Kommentarzeilen wie Codezeilen haben
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."

Und wenn es nur jeweils ein Block
über jeder Funktion ist der erklärt was diese tut.
Das schon eher. Das sollten aber kaum so viele Zeilen Kommentar wie Code
sein. Und noch so viel Kommentar kann keine gute Dokumentation ersetzen.

Schon, aber man kann in C und anderen Sprachen, u.a. auch PERL schönen
write-only-Code schreiben.
Was heißt "write-only-Code"?

 

[Gerrit Heitsch]

On 11/07/2013 12:26 PM, Hartmut Kraus wrote:

Am 06.11.2013 20:31, schrieb Gerrit Heitsch:

Schon, aber man kann in C und anderen Sprachen, u.a. auch PERL schönen
write-only-Code schreiben.
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

 

[Hartmut Kraus]

Am 07.11.2013 19:21, schrieb Gerrit Heitsch:

On 11/07/2013 12:26 PM, Hartmut Kraus wrote:
Am 06.11.2013 20:31, schrieb Gerrit Heitsch:

Schon, aber man kann in C und anderen Sprachen, u.a. auch PERL schönen
write-only-Code schreiben.
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...

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".

 

[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+(.*?)$/)

# "
{
$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...
Das ist ja auch nicht unbedingt nötig, wenn's funktioniert, ist's doch
ok. Vorausgesetzt, man kann absichern, dass keine "Nebenwirkungen"
auftreten.

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.

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".

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

 

[Carsten Thumulla]

Hartmut Kraus schrieb:

Am 07.11.2013 19:21, schrieb Gerrit Heitsch:

Wenn du das gerade geschrieben hast verstehst du es natürlich noch und
kannst Änderungen durchführen. Aber schon einen Tag später...
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".

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.

 

[Hartmut Kraus]

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+(.*?)$/)

# "
{
$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...
Das ist ja auch nicht unbedingt nötig, wenn's funktioniert, ist's doch
ok. Vorausgesetzt, man kann absichern, dass keine "Nebenwirkungen"
auftreten.

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.



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".

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'.

Ähm nee, ich teste doch nicht den Code mit igendwelchen mäkligen
Vailiderungsprogrammen, sondern das, was das Programm zu Laufzeit
anrichtet.

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

Am 08.11.2013 07:40, schrieb Carsten Thumulla:

> Und der Müllhaufen der unwartbaren Software wächst weiter.
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.

Wir stecken
noch in der Softwarekrise mittendrin, die meisten merkens nur nicht mehr.

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:

http://www.channelpartner.de/forum/kommentare-unseren-nachrichten/1936-microsoft-schiebt-apertum-abstellgleis-software-geschichte.html#post6880

http://www.channelpartner.de/index.cfm?pid=54&pk=630115

 

[Oliver Betz]

Gerrit Heitsch schrieb:

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...

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/

 

[Gerrit Heitsch]

On 11/09/2013 07:02 PM, Oliver Betz wrote:

Gerrit Heitsch schrieb:

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...

das halte ich für kein gelungenes Beispiel, denn der Ausdruck ist
recht gradlinig und nicht sonderlich schwer zu verstehen.

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

 

[Oliver Betz]

Gerrit Heitsch schrieb:

[...]

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

das halte ich für kein gelungenes Beispiel, denn der Ausdruck ist
recht gradlinig und nicht sonderlich schwer zu verstehen.

Wenn man sich dauernd mit PERL beschäftigt, dann geht das halbwegs. Wenn

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/

 

[Sieghard Schicktanz]

Hallo Hartmut,

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

Des weiteren gehĂśrt dem Programmierer, der so mit Kommentaren geizt, mal
feste in den Hintern getreten.
NĂś.

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

"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?"

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

Und wenn es nur jeweils ein Block
ßber jeder Funktion ist der erklärt was diese tut.
Das schon eher. Das sollten aber kaum so viele Zeilen Kommentar wie Code
sein. Und noch so viel Kommentar kann keine gute Dokumentation ersetzen.

Kommentar _ist_ Dokumentation, und zwar Dokumentation fĂźr den
Programmierer, dem, der das Original schrieb fßr später, oder einem
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Ăźrzt
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
-----------------------------------------------------------

 

[Sieghard Schicktanz]

Hallo Carsten,

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

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

Optimist.

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

 

[Hartmut Kraus]

Am 10.11.2013 19:37, schrieb Sieghard Schicktanz:

Hallo Carsten,

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

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

Optimist.

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.

 

[Hartmut Kraus]

Am 10.11.2013 19:33, schrieb Sieghard Schicktanz:

Hallo Hartmut,

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

Des weiteren gehört dem Programmierer, der so mit Kommentaren geizt, mal
feste in den Hintern getreten.
Nö.

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

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.

"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?"

Deswegen sollst Du ja nicht beschreiben, _wie_ der Code arbeitet, sondern
kommentieren, _was_ er tut.
Kommt auf's selbe 'raus.

Und wenn es nur jeweils ein Block
über jeder Funktion ist der erklärt was diese tut.
Das schon eher. Das sollten aber kaum so viele Zeilen Kommentar wie Code
sein. Und noch so viel Kommentar kann keine gute Dokumentation ersetzen.

Kommentar _ist_ Dokumentation, und zwar Dokumentation für den
Programmierer, dem, der das Original schrieb für später, oder einem
anderen, der daran mal weiterarbeitet.
Meine Güte, ich hab' mal an einem Teil dieser Software mitgearbeitet:

http://www.gap-group.de/produkte/uebersicht.html

(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.

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ürzt
sind. Namen wie "ptr" oder "buf" sind da noch herausragende Beispiele für
Offensichtlichkeit.

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