Bin ich zu Blöd dafür

[SMiller]

@Christian Fein
Ich hoffe du missverstehst mich jetzt nicht, meine es gut:
[klugschei*]
Man kann ist was anderes als Mann kann, also wenn du die Männer unter uns ansprechen willst, dann müsstest du es schon groß schreiben, ansonsten sollte man "man" mit einem n schreiben.

Nur so 'ne kleine Bemerkung nebenbei, habe es in vielen Beiträgen entdeckt bei dir. Schadet ja nicht zu sagen hoffe ich...
(das und dass sind wohl auch nicht so die Stärken von dir)
[/klugschei*]

 

[Christian Fein]

Original geschrieben von SMiller
@Christian Fein
Ich hoffe du missverstehst mich jetzt nicht, meine es gut:
[klugschei*]
Man kann ist was anderes als Mann kann, also wenn du die Männer unter uns ansprechen willst, dann müsstest du es schon groß schreiben, ansonsten sollte man "man" mit einem n schreiben.

Nur so 'ne kleine Bemerkung nebenbei, habe es in vielen Beiträgen entdeckt bei dir. Schadet ja nicht zu sagen hoffe ich...
(das und dass sind wohl auch nicht so die Stärken von dir)
[/klugschei*]

Ne kein Problem, ich bin der beste Beweis das Leute mit Rechtschreibschwäche auf tutorials.de nicht kommentarlos gekickt werden

Ne nehm ich nicht übel auf, ist mir nur bekannt, aber wie heisst es so schön, was das Hänschen nicht lernt ...

 

[squeaker]

Original geschrieben von Christian Fein
Um Zusammenhänge zu dokumentieren sind JUnit wirklich eine sehr gute Wahl, denn
mann erkennt wie wird ein ein Teil angewendet, welche Ergebnisse werden erwartet und
weiteres.

Ich betone nochmals es gibt Dinge die zu dokumentieren sind, aber ganz oft sind Dinge
einfach falsch wenn sie eine ausgiebige Dokumentation benötigen.

Naja, wir reden hier ja nicht darüber ob etwas schlecht oder gut designt wurde. Aber auch gut designte Anwendungen bedürfen Dokumentation und die häufig verwendeteten Teile dürfen meiner Meinung nach auch optimiert werden. Mir geht die Ressourcenverschwenderrei ein wenig auf den Keks. Man muss es ja nicht gleich so übertreiben wie Farbrausch, die einen 3D-Shooter in 96kByte gepackt haben, aber so ein bischen weniger Verschwendung würde schon helfen.

 

[Christian Fein]

Original geschrieben von squeaker
Naja, wir reden hier ja nicht darüber ob etwas schlecht oder gut designt wurde. Aber auch gut designte Anwendungen bedürfen Dokumentation und die häufig verwendeteten Teile dürfen meiner Meinung nach auch optimiert werden.

Kommentare != Dokumentation

Eine Dokumentation ist weitereichender und sehr wichtig. Kommentare im meisten Fall
eher störend als fördernd.

Eine Dokumentation erklärt wie die Zusammenhänge sind und zeigt dies evtl auch Grafisch da, kommentare die irgendwo im Code versteckt sind wollen oft schlechten Code kaschieren.

 

[Dudadida]

Will ich meinen Senf auch mal dazugeben. Wenn es nicht super trivial und einleuchtend ist gehört meiner Meinung nach vor jede Funktion/Methode eine kleine Erläuterung was die Aufgabe der Funktion/Methode ist und ein Hinweis darauf, wie es realisiert wird. Außerdem gehört an kritische (meine komplizierte) Codestellen zumindest ein Verweis auf den Algorithmus den man verwendet, wenn es ein allgemein bekannter ist, oder eine kleine Erläuterung wie er funktioniert. Jeder der schonmal auch nur seinen eigenen Code nach einem Jahr oder so versucht hat nachzuvollziehen, weiß, wie nützlich Kommentare sein können.

Original geschrieben von squeaker
Mir geht die Ressourcenverschwenderrei ein wenig auf den Keks. Man muss es ja nicht gleich so übertreiben wie Farbrausch, die einen 3D-Shooter in 96kByte gepackt haben, aber so ein bischen weniger Verschwendung würde schon helfen.

Amen!

 

[Christian Fein]

Original geschrieben von Dudadida
Jeder der schonmal auch nur seinen eigenen Code nach einem Jahr oder so versucht hat nachzuvollziehen, weiß, wie nützlich Kommentare sein können.

Wenn das nicht funktioniert liegt das Problem am Code und nicht an fehlenden Kommentaren.
Wenn ich noch nichtmal meinen eigenen Code nachvollziehen kann, wer sollte es sonst noch können.

Sprich wenn das nicht funktioniert muss mann seine komplette Art und Weise wie mann programmiert hinterfragen.

Hier sollte mann die Ursache bekämpfen.

 

[Dudadida]

Ein komplizierter Algorithmus bleibt ein komplizierter Algorithmus, egal wie "schön" ich ihn schreibe. Wenn es keine sehr trivialen Aufgaben sind, dann muss man sich halt an irgendeiner Stelle mal die Gehirnwindungen verrenken um zur Lösung zu kommen und wenn man seinen Schritt dann nicht kommentiert, kann es gut sein, dass man in einem Jahr nicht mehr weiß, was man sich da gedacht hat. Einfaches Bsp.: Schnittpunkt zwischen Gerade und Ebene im Raum. Wenn man das geometrisch löst - und das geht recht gut - hat man einfach nur 2 Zeilen - und sowas packe ich sicher nicht der Struktur zuliebe in unterschiedliche Funktionen oder so -, die einem aber, wenn man darüber nachdenkt wirklich nicht wie Schuppen von den Augen fallen. Wenn man dann nicht kommentiert, muss man nochmal komplett neu herleiten und das ist sicherlich nicht sehr effektiv. Vor allem kann man ohne Kommentar bei solchen Algorithmen Fehler sehr schlecht finden, wenn sie auftreten, eben weil man gezwungen ist nochmal herzuleiten und ein Fehler finden auf den ersten Blick unmöglich wird.

 

[Christian Fein]

Original geschrieben von Dudadida
Ein komplizierter Algorithmus bleibt ein komplizierter Algorithmus

Besteht dein Programm nur aus mathematisch komplexen Algorythmen?
Wahrscheinlich nicht, nur hier und da kommt das bei Knackpunkten vor, das erklärt aber noch
lange kein bis zu unleserlichkeit mit Kommentaren zugeschissener Code wie mann ihn allzuhäufig leider gottes sieht.
Viel sinnlose kommentare, aber keine Dokumentation.

Glaube mir eins, ich bin da ein gebranntes Kind da ich eine Software anpassen durfte die
genau so verunstalltet war bis zur Unlesbarkeit.
Gegen ein - zwei kommentare an wirklich verständlichen Stellen gibts nichts gegen einzuwenden, habe ich auch nichts dagegen gesagt.
Aber allzu häufig wird falsch Designter Code nachträglich kommentiert um "nach einem
Jahr lesbar" zu sein. Das geht aber nach hinten los, denn wenn ein Code in jeder Klasse
mehrere Kommentare enthält ohne die mann mit diesem Code nicht arbeiten könnte, dann
ist der Code einfach schlecht!
Das währe dann der richtige Zeitpunkt extremes Refactoring zu betreiben.

Wenn ich eine komplizierte Geschichte habe, dann setze ich mich solange hin und schreibe die
Methode bis sie wunderbar läuft. Danach muss ich sie mir nicht mehr anschauen sondern nur noch aufrufen. Und wie der Algorythmus abläuft ist mir soziemlich egal, mich interressiert ein Jahr später nur noch Was stecke ich hinein und was bekomme ich heraus.

Ein Fehler sollte grundsätzlich nicht auftreten. Wenn sich in einer Methametischen Bereichnung ein Bug eingeschlichen hat, dann ist es Zeit diese Bereichnung komplett wegzuwerfen da sie nicht vertrauenswürdig ist.
Läuft sie jedoch fehlerfrei so muss ich sie nur anwenden.

 

[squeaker]

Original geschrieben von Christian Fein
Besteht dein Programm nur aus mathematisch komplexen Algorythmen?
Wahrscheinlich nicht, nur hier und da kommt das bei Knackpunkten vor, das erklärt aber noch
lange kein bis zu unleserlichkeit mit Kommentaren zugeschissener Code wie man ihn allzuhäufig leider gottes sieht.

Wir reden hier nicht von schlechten Kommentaren. Und ja, viele Probleme sind mathematisch komplexe Algorithmen. Die sollten erst einmal Dokumentiert sein (was macht der Algorithmus und wie macht er es) und dann sollten bei solchen Problemen bei denen es auf Performanz ankommt (String matching z.B., Datenkompression, Verschlüsselung, Rechtschreibkorrektur, 3D-Graphik, Simulation um nur ein Paar zu nennen) Optimierungen vorgenommen werden und diese, sofern sie nicht algorithmischer Natur sind auch im Quelltext kommentiert werden. Dies ist essentiell und je näher die Sprache dem Prozessor steht, um so mehr werden Kommentare benötigt. Dies geht soweit, dass in ASM die meisten Zeilen kommentiert sein sollten.
Smalltalk hingegen braucht man kaum kommentieren, da sogar die Parameterübergabe in Sprachähnlicherform geht (Beispiel: decompressFile: aFilename withAlgorithm: anAlgorithm - sähe in Java so aus: decompress(String filename, Algorithm algo).

in Asm z.B.:

push eax ; eax=Adresse des Algorithmus
push ebx ; ebx=Adresse des String
call decompress

hier sind Kommentare bitter notwendig und ohne ist man aufgeworfen (ich habe mich schon an reverse-engineering probiert - ist echt schwierig ohne Kommentare).

Ich glaube du Programmierst ein einem Anwendungsprofil wo deine Verhaltensweise sicher angebracht ist. Ausserdem hast du sicher häufig gesehen wie man es nicht macht. Daraus zu schliessen, dass (fast) jeder Kommentar unnötig ist halte ich aber für fragwürdig

 

[Christian Fein]

Original geschrieben von squeaker

Ich glaube du Programmierst ein einem Anwendungsprofil wo deine Verhaltensweise sicher angebracht ist. Ausserdem hast du sicher häufig gesehen wie man es nicht macht. Daraus zu schliessen, dass (fast) jeder Kommentar unnötig ist halte ich aber für fragwürdig

Was ich ausdrücken will:

Kommentiere mit bedacht. Wenn mann bemerkt das ein Kommentar nötig ist weil mann sonst den betreffenden Teil nicht versteht, sollte mann erst überlegen wie kann ich es Umbauen das
es leicht verständlich wird.

Ein kleiner Code, etwas übertrieben kommentiert in der ersten Version. Es soll aber
nur deutlich machen das viele Dinge viel lesbarer werden wenn mann sich ein
bischen Gedanken macht.

Iterator iterator = accaunts.iterator();
int i  =0 ;
int status = 0;
while(iterator.hasNext() { 
    i++;
    Accaunt current = (Accaunt)iterator.next();
    //  wenn nächster Accaunt null ist, ist aktueller auf jeden fall grösser
    if(accaunts.get(i) == null ||
     // check ob Quota grösser als Quota nächster accaunt
      ( current.getQuota() > accaunts.get(i).getQuota() &&
       // status muss status des Prototypes entsprechen
       current.getStatus() == prototype.getStatus() ) ) {
       // tu irgendwas
     } else {        
       // Fehler status muss auf -1 gesetzt werden 
       status = -1;
     }
}

besser umschreiben in

AccIterator aIterator = accaunts.iterator();
int status = 0;
while(iterator.hasNext() { 
    Accaunt current = aIterator.getNext();
    Accaunt afterCurrent = aIterator.getAfterCurrent();
    if(isCurrentQuotaBigger(current,afterCurrent,prototype) {
       // tu was
    } else  {
       status = -1;
    }
}

private boolean isCurrentQuotaBigger(Accaunt current, Accaunt afterCurrent, Accaunt prototype) {
    if(afterCurrent==null) return false;
    if(current.getQuota() <= afterCurrent.getQuota()) return false;
   return true;
}

Ich muss mir nicht die Methode isValid anschauen um die while schleife zu verstehen. Ich lese isCurrentQuotaBigger als Methodename der mir genau sagt was die Methode denn vergleichen will, da ich current und afterCurrent übergebe erkenne ich auch was denn
genau verglichen wird.
Zumal habe ich im ersten Beispiel sinngemäss folgendes Konstrukt:
if( naechstesCurrent == null ||
diesesCurrent > naechstesCurrent)
Das heisst die Logic sagt das der current accaunt aufjedenfall grösser als der nächste
ist wenn dieser null ist.
Aber mein gott muss ich mich ein Jahr später mit dieser Logik auch befassen wenn ich mich
in das Projekt einlese? Nein nicht wirklich ich habe es in eine Methode gepackt die das abhandelt, wie die Methode implementiert ist brauch ich mir erst anzuschauen wenn ichs wirklich wissen muss.

Ist vielleicht kein Top Beispiel aber ich hoffe ich das macht klar was ich meine.