Eure besten Quellcode Kommentare...

[himitsu]

Oder wie in den Indy, wo niemand es hinbekam ein Synchronisationsobjekt aufzuräumen, bzw. dass vor dessen "geplanter" Freigabe alle Abhängigen auch freigegeben sind,
und sie es daher sich sagen "Windows räumt am Ende eh auf", also lassen wir es einfach und damit keiner Denkt wir sind doof, verstecken registrieren wir diesen Speicher eben.

[Neutral General]

Delphi-Quellcode:

{$IFDEF MSWINDOWS}
procedure DLLShutdown; stdcall;
begin
  try
    if @DLLShutdownProc <> nil then
      DLLShutdownProc;
  finally
    // eat all exception.
  end;
end;
{$ENDIF MSWINDOWS}

[MaBuSE]

Zitat:

Zitat von Neutral General (Beitrag 1456748)

Delphi-Quellcode:

...
  finally
    // eat all exception.
  end;
...

Der ist gut :shock::lol::lol::lol:

Aber sicherlich hat er zufällig (quasi aus versehen) die Exception in der aufrufenden Methode abgefangen :thumb:

[freimatz]

Ausnahmsweise finde ich: Das ist wirklich gut. Wenn auch nur in diesem recht exotischen Fall und für eine Release-Version.
Bei denem Zitat hast du was wichtiges weggelassen so z.B. "DLLShutdown". Ich vermute es geht hier um die letzte Methode in einer DLL. Was soll denn die DLL mit der Exception machen. Vermutlich sind doch schon alle Systene runtergefahren die noch eine Möglichkeit der Behandlung bieten würde. (Vielleicht ginge noch ein Aufruf an madExcept oder so.) Die Exception an den zu überlassen, der die DLL entlädt hilft m.E. auch nicht weiter.

Aber ich pflichte den meisten bei, in den meisten Fällen ist das Schlucken aller Exception einfach nur :kotz:

[Neutral General]

Die DLLShutdown-Methode die ich gepostet habe ist übrigens aus der System.pas. (10.3.2)
Genau so geschrieben und kommentiert.

@freimatz: Der Witz an der Sache ist, dass das finally die Exceptions nicht mal "eatet".
Das Try-Finally tut rein gar nichts. Was (laut Kommentar) gewollt wäre, ist ein try-except mit einem leeren except-Block.

[philipp.hofmann]

Ok, danke. Ich habe echt schon an mir gezweifelt, was das finally hier bitte schön "eaten" soll.

[freimatz]

Ah so jetzt ja. Sorry :duck:

[MaBuSE]

Zitat:

Zitat von Neutral General (Beitrag 1456837)

Die DLLShutdown-Methode die ich gepostet habe ist übrigens aus der System.pas. (10.3.2)
Genau so geschrieben und kommentiert.

:shock:

Zitat:

Zitat von Neutral General (Beitrag 1456837)

@freimatz: Der Witz an der Sache ist, dass das finally die Exceptions nicht mal "eatet".
Das Try-Finally tut rein gar nichts. Was (laut Kommentar) gewollt wäre, ist ein try-except mit einem leeren except-Block.

Genau. Deshalb hatte ich ich ja noch geschrieben, dass es hoffentlich noch drüber abgefangen wird.

Zur Erklärung:
[EDIT]
Ich habe diesen (langen Text) in ein eigenes Thema verschoben, dort kann auch dazu diskutiert werden. :thumb:

Kleiner Exkurs zu Exceptions (try finally/except):
https://www.delphipraxis.net/203329-...ly-except.html

[/EDIT]

[freimatz]

Das haste jetzt hoffentlich nicht wegen mir zusammengebröselt :shock:

[MaBuSE]

Zitat:

Zitat von freimatz (Beitrag 1456855)

Das haste jetzt hoffentlich nicht wegen mir zusammengebröselt :shock:

Äh, doch :-D :thumb:

Vielleicht findet es ja noch der ein oder andere interessant.

[freimatz]

Delphi-Quellcode:

// Lieber Mit-Entwickler: Bitte diesen Zähler um 1 erhöhen,
// wenn Du auch versucht hast diesen Quellcode zu vereinfachen
// und am Ende aufgeben musstest
const complexityCounter = 13;

[Der schöne Günther]

Delphi-Quellcode:

   try
      Win32Check(
         WinApi.Windows.MoveFileEx(
            PChar(filePath_auxilary),
            PChar(filePath_real),
            flags
         )
      );
   except
      // make a sad face
    end;

Ich liebe diese Exception-Blöcke 😎

[Codehunter]

Zitat:

Zitat von Der schöne Günther (Beitrag 1457469)

Delphi-Quellcode:

   try
      Win32Check(
         WinApi.Windows.MoveFileEx(
            PChar(filePath_auxilary),
            PChar(filePath_real),
            flags
         )
      );
   except
      // make a sad face
    end;

Ich liebe diese Exception-Blöcke 😎

Wirft das Win32-Gedöns überhaupt eine Exception?

[Der schöne Günther]

Ich hätte spontan gesagt dass genau das sein Zweck ist.

http://docwiki.embarcadero.com/Libra...ils.Win32Check

[Codehunter]

Zitat:

Zitat von Der schöne Günther (Beitrag 1457478)

Ich hätte spontan gesagt dass genau das sein Zweck ist.

http://docwiki.embarcadero.com/Libra...ils.Win32Check

Das meine ich ja :lol: MoveFileEx wirft erstmal keine Exception. Dann wurde da Win32Check drumrumgebaut um ggf. eine Exception auszulösen, welche man dann im except-Abschnitt geschmeidig ignoriert. Ist das jetzt Laufzeitdeoptimierung?

[Der schöne Günther]

Ich denke mal das hat bislang überlebt weil Exceptions immerhin noch gelogged werden. Anders kann ich mir es auch nicht erklären 😄

Zitat:

Zitat von Codehunter (Beitrag 1457481)

Laufzeitdeoptimierung?

Alles was das Programm nicht umbringt macht es nur härter.

[DeddyH]

Wenn Programme zu schnell arbeiten, sieht man ja den mühevoll gestylten Splash-Screen evtl. nicht :stupid:

[Luckie]

Interessant. Ab welchem Delphi ist das verfügbar?

[Neutral General]

Seit ca. schon immer soweit ich weiß.

[Codehunter]

Zitat:

Zitat von Der schöne Günther (Beitrag 1457483)

Alles was das Programm nicht umbringt macht es nur härter.

Oder hartleibig. Alles eine Frage der Definition :lol:

Zitat:

Zitat von DeddyH (Beitrag 1457487)

Wenn Programme zu schnell arbeiten, sieht man ja den mühevoll gestylten Splash-Screen evtl. nicht :stupid:

Weshalb ich den ja auch bei meinen Programmen in einen separaten Prozess auslagere, mit dem ich per Messages o.ä. kommuniziere. Der bleibt dann einfach n Sekunden lang sichtbar, egal ob das Hauptprogramm fertig hat oder nicht :-D

[dummzeuch]

Zitat:

Zitat von Luckie (Beitrag 1457488)

Interessant. Ab welchem Delphi ist das verfügbar?

Wenn Du Win32Check meinst:
Das habe ich schon mit Delphi 3 verwendet, mich würde nicht wundern, wenn es auch in Delphi 2 schon existierte. (In Delphi 1 gab es soweit ich weiß keine Exceptions.)

[DeddyH]

Zitat:

Zitat von dummzeuch (Beitrag 1457519)

(In Delphi 1 gab es soweit ich weiß keine Exceptions.)

Doch, gab es ;-)

[Codehunter]

Zitat:

Zitat von DeddyH (Beitrag 1457521)

Zitat:

Zitat von dummzeuch (Beitrag 1457519)

(In Delphi 1 gab es soweit ich weiß keine Exceptions.)

Doch, gab es ;-)

Hießen die damals noch Regeln bevor sie zu Ausnahmen wurden? :lol:

[Luckie]

Ich war auch etwas offtopic. Aber ich denke, wir sollten wieder zum eigentlichen Thema zurückkommen und in dem geht es um Quellcodekommentare, um das noch mal in Erinnerung zu rufen.

[Der schöne Günther]

Variablen gute Namen zu geben ist auch gute Kommentierung, aber das sieht so spooky aus, das traue ich mich erst gar nicht anzufassen. Warum Sleep 0? Und warum "wharrgarbl"? Eine Bildersuche nach dem Begriff lässt mich nur noch verwirrter zurück...

Delphi-Quellcode:

const
   WHARRGARBL = 0;
begin
   TTask.Run(
      procedure()
      begin
         TThread.Sleep(WHARRGARBL);
         TThread.Queue(
            TThread.CurrentThread,
            procedure()
            begin
               runPageAdjustments();
            end
         );
      end
   );
   // TODO und was ist wenn man es vor ablauf wieder schließt?
end;

[Rollo62]

Zitat:

Zitat von Der schöne Günther (Beitrag 1495047)

Delphi-Quellcode:

const
   WHARRGARBL = 0;

Das ist doch mal ein schöner "sprechender Name", der den aktuellen Gemütszustand des Programmierers ausdrückt :stupid:

[Codehunter]

Zitat:

Zitat von Der schöne Günther (Beitrag 1495047)

Warum Sleep 0?

Spontane Idee: War mal <> 0 zum Testen und wurde irgendwann auf 0 gesetzt anstatt die Zeile ganz zu entfernen.

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1495047)

Warum Sleep 0?

Das kann schon seinen Sinn haben. Das Sleep ist ja unter Windows intern auf die gleichnamige Windows-Routine verdrahtet und dazu sagt MSDN:

Zitat:

A value of zero causes the thread to relinquish the remainder of its time slice to any other thread that is ready to run. If there are no other threads ready to run, the function returns immediately, and the thread continues execution. Windows XP: A value of zero causes the thread to relinquish the remainder of its time slice to any other thread of equal priority that is ready to run. If there are no other threads of equal priority ready to run, the function returns immediately, and the thread continues execution. This behavior changed starting with Windows Server 2003.

[Medium]

Jap, das ist genau warum ich das auch gerne mal einsetze. Sonst schnappt sich ein Thread der sonst auf nichts wartet nämlich einfach mal 100% CPU Auslastung.

[Der schöne Günther]

Dann hätte man aber auch

Delphi-Quellcode:

TThread.Yield()

sagen können anstatt

Delphi-Quellcode:

WHARRGARBL

- glaube ich.

[MaBuSE]

Zitat:

Zitat von Medium (Beitrag 1495051)

Jap, das ist genau warum ich das auch gerne mal einsetze. Sonst schnappt sich ein Thread der sonst auf nichts wartet nämlich einfach mal 100% CPU Auslastung.

Dann passt doch der Name ;)

Zitat:

TOP DEFINITION ( https://www.urbandictionary.com/defi...erm=WHARRGARBL )

WHARRGARBL

1. The caption of a popular "loldog" (dog version of lolcat) showing a dog attempting to drink from a lawn sprinkler. Word refers to the sound the dog presumably is making as it angrily (and pointlessly) attempts to subdue the water stream. (The sound dogs make when they attempt to drink out of lawn sprinklers.)
2. A one-word stand-in for any angry, incoherent, pointless reaction, comment, or attack. In online forums, the loldog referenced in (1) is often used to make the point that someone's position is incoherent, illogical, and or pointless. Simply writing 'WHARRGARBL' is also sufficient to make the point, and is especially effective if the target of your insult is one of the few people unfamiliar with the loldog.

Note that incoherence or pointlessness is required for a proper WHARRGARBL reference. An angry, but otherwise logical, argument is not a WHARRGARBL. An argument that takes a reasonable (or at least arguable) position, but does so with an incoherent rant IS a valid WHARRGARBL.

Coherence and logic (or the lack thereof) is in the eye of the beholder, of course. On the internets, any argument that disagrees with yours may be a valid WHARRGARBL.

[himitsu]

Manmal würde ich mir wünschen, wenn es überhaupt Kommentare oder wenigstens eine halbwegs verständliche Hilfe gäbe,
aber wenn man schon tagelang verzweifelt sucht und von einem Problem ins nächste stolpert,
und dann einen Artikel findet, ala "The Worst API Ever Made",
dann vergeht einem auch das letzte Bissl an Lust.

Wenn ich mal was fand und dort standen Kommentare ... dann stimmten sie garnicht. :freak:

Und der einzige gut aussehende Code, als Antwort auf eine Frage ....... der bracht mitten drin ab. :wall:



https://caseymuratori.com/blog_0025

Hatte die überschrift erst garnicht gesehn und dachte "geil", endlich mal was, das ausführlich aussieht und wirklich um das geht, was ich suche (nicht um irgendwas anderes, mit dem Wort "Trace")

[MaBuSE]

Zitat:

Zitat von himitsu (Beitrag 1512429)

Manmal würde ich mir wünschen, wenn es überhaupt Kommentare oder wenigstens eine halbwegs verständliche Hilfe gäbe,

Das kenne ich.

Ich habe auch schon Projekte gesehen, die mehrere Mio Zeilen Quelltext lang sind und per Definition in ca. einer Stunde entstanden sein müssen. :shock:
Na ja, bei uns gibt es eine Arbeitsanweisung, dass ca. 10% der Zeit für Dokumentation einzuplanen ist.
Und der/die Entwickler haben sich nicht mal 10 Min Zeit genommen für Doku und Kommentare.

[dummzeuch]

Besser gar keine Kommentare als falsche oder sinnlose ala

Delphi-Quellcode:

// *******************
// * Prozdur bla     *
// *******************
procedure bla;
var
  i: integer; // Schleifenvariable
begin
  // alle Listenelemente durchlaufen
  for i := 0 to Liste.Count -1 do begin
    // Listenelement verarbeiten
    Process(Liste[i]);
  end;
end;

letztere reduzieren die Lesbarkeit ohne irgendwas beizutragen.

Programmierer sollten sich besser auf verständlichen Code (Struktur und Namensgebung) konzentrieren als auf Teufel komm raus Kommentare zu schreiben. Kommentare sollen beschreiben, warum etwas auf eine bestimmte Weise gemacht wird, und das auch nur dann, wenn es nicht offensichtlich ist.

[DeddyH]

:thumb:

[Uwe Raabe]

Zitat:

Zitat von dummzeuch (Beitrag 1512453)

Programmierer sollten sich besser auf verständlichen Code (Struktur und Namensgebung) konzentrieren als auf Teufel komm raus Kommentare zu schreiben. Kommentare sollen beschreiben, warum etwas auf eine bestimmte Weise gemacht wird, und das auch nur dann, wenn es nicht offensichtlich ist.

:thumb:

Zitat:

Zitat von Brian W Kernighan and P. J. Plaugher

Don't comment bad code - rewrite it.

[himitsu]

Dein Beispiel klingt wie die Hilfe einer gewissen Firma.

Zitat:

Ohh, ein neues Property, mit unverständlichem Namen
...

[F1]
mal gucken was das machen soll

Zitat:

Zitat von OH

Das ist Property Abc in Klasse Xyz der unit Qrs.

UND WAS MACHT DAS NUN?

Genauso wie "oh, komischer Prozess" im Taskmanager .... fragen wir mal G/Y/B/... und die Top10 Suchergebnisse sagen alle

Zitat:

das ist Abc.exe soundsogroß in Verzeichnis hierundda der Firma "NameAusVersionsresource"

UND WAS MACHT DIE NUN?

Das ALLES wusste man auch vorher schon.



Es gibt in Firmen teilweise vorschriften, wonach x% des Quellcodes Kommentare sein müssen.

Da kommt dann auch oft sowas bei raus.

[MaBuSE]

Zitat:

Zitat von himitsu (Beitrag 1512456)

Es gibt in Firmen teilweise vorschriften, wonach x% des Quellcodes Kommentare sein müssen.
Da kommt dann auch oft sowas bei raus.

In Deiner Brust scheinen 2 Herzen zu schlagen ;)

Einerseits schreibst Du, dass wenn Firmen den Entwicklern vorschreiben, sie möchten bitte dokumentieren (Quellcode, Handbücher, Readme, ...), oft nur Müll rauskommt.

Zitat:

Zitat von himitsu (Beitrag 1512429)

Manmal würde ich mir wünschen, wenn es überhaupt Kommentare oder wenigstens eine halbwegs verständliche Hilfe gäbe,
aber wenn man schon tagelang verzweifelt sucht und von einem Problem ins nächste stolpert,...

Andererseits möchtest Du in Quellcode Kommentare und "wenigstens eine halbwegs verständliche Hilfe" haben.

Zitat:

Zitat von MaBuSE (Beitrag 1512445)

Ich habe auch schon Projekte gesehen, die mehrere Mio Zeilen Quelltext lang sind und per Definition in ca. einer Stunde entstanden sein müssen. :shock:
Na ja, bei uns gibt es eine Arbeitsanweisung, dass ca. 10% der Zeit für Dokumentation einzuplanen ist.
Und der/die Entwickler haben sich nicht mal 10 Min Zeit genommen für Doku und Kommentare.

Bei uns gibt es die Richtlinie, dass in der Zeitschätzung ca. 10 % für Dokumentation vorzusehen sind.
Das beinhaltet Quellcode Kommentare, Readme Dateien, Installations-Anweisungen, Benutzerbücher, ...

Der Entwickler nutzt die 10% aber lieber als Puffer um seine Arbeit fristgerecht abzuschließen. Doku ist ja nicht wichtig. :(

[himitsu]

Das Beispiel aus #514, hatten wir hier öfters mal.

Grade in dem was man in einigen Schulen lernen soll, da war wirklich jede einzelne Zeile kommentiert, was da gemacht wird, auch wenn 95% davon der Quellcode selber gesagt hat nd weitere 4%, wenn man ordentliche Namen für Variablen/Funktionen benutzt hätte.
Nur die eine Zeile, die jemand nicht verstand, weil es dem Code nicht richtig anzusehn ist, was ermacht, das war Die ohne Kommentar.



Kommentare nur um des Kommentares Willen, ohne dass er einen Mehrwert bringt, außer den Code zwischen sich untergehen zu lassen ... nja

[Maliko]

Zitat:

Zitat von dummzeuch (Beitrag 1512453)

Besser gar keine Kommentare als falsche oder sinnlose ala

Delphi-Quellcode:

// *******************
// * Prozdur bla     *
// *******************
procedure bla;
var
  i: integer; // Schleifenvariable
begin
  // alle Listenelemente durchlaufen
  for i := 0 to Liste.Count -1 do begin
    // Listenelement verarbeiten
    Process(Liste[i]);
  end;
end;

Leider gibt es immer wieder Firmen die genau sowas wollen. Ich war mal in einer Firma, da sah der Quellcode genauso aus, weil der Entwicklungsleiter darauf bestanden hat, dass jede einzelne Zeile Code kommentiert werden muss. Da kommt dann so ein Müll bei raus. Manchmal habe ich fürs Kommentieren länger gebraucht als für das Schreiben der Funktion.