Eure besten Quellcode Kommentare...

[Memnarch]

@Himitsu:
Pack mal inen Funktionsnamen nen LR-Overwrite Character rein. Das ist lustig :D. Dann kannst du die dinge Teils spiegelverkehrt schreiben, und IDE und Compiler schluckens :D

[himitsu]

Geil, Variable rückwärts schreiben und umgedreht anzeigen.
Selbst wenn jemand den Namen abschreibt und sich in deine Klasse häcken will, dann kompiliert nichts, weil er ja verkehrtrum schreibt. :lol:




Die extrem jugendgefährdeten Kommentare hab ich aber besser mal weggelassen.
Sorry, war etwas genervt.
TJSONObject.ParseJSONValue gibt einfach wortlos NIL zurück, und keine Ahnung warum, denn in der Datei ist jetzt ein valides JSON-Objekt drin.
Vorher JSONObject.ToString entdeckt, dass es totalen Schrott produziert, wie z.B. keine " und sonstige Steuer und Nicht-ASCII-Zeichen zu kodieren, aber vorallem \ und " unkodiert zu lassen ist der Megaburner und gehört eigentlich mit Steinigung bestraft.
Und JSONObject.Parse hört einfach mitten drin auf, wenn ihm was nicht gefällt und lässt dann netterweise defekte/unvollständige Subobjekte zurück.
Delphi DBXJSON.pas aus Delphi XE.

Delphi-Quellcode:

J := TJSONObject.Create;
try
  J.AddPair(...);
  J.AddPair(...);
  ...

  // der DRECK im ToString kodiert die Steuerzeichen nicht
  //TFile.WriteAllText(Datei, J.ToString, TEncoding.UTF8);
  B := TEncoding.UTF8.GetPreamble;
  i := Length(B);
  SetLength(B, i + J.EstimatedByteSize);
  J.ToBytes(B, i);
  while B[High(B)] = 0 do Delete(B, High(B), 1);  // Trim, denn EstimatedByteSize gibt etwa 4 Mal zuviele Bytes zurück
  TFile.WriteAllBytes(Datei, B);
finally
  J.Free;
end;

//J := TJSONObject.ParseJSONValue(TFile.ReadAllText(Datei)) as TJSONObject;
J := TJSONObject.Create;
try
  J.Parse(TFile.ReadAllBytes(Datei), Length(TEncoding.UTF8.GetPreamble));

  // Bei Ladefehler hat das letzte SubObjekt (Size-1) eventuell keinen Namen und es knallt dann bei der Namenssuche
  if not Assigned(J) then
    raise Exception.Create('Fehler beim Laden der Datei');
  if not ((J.Size > 0) and Assigned(J.Get(J.Size-1).JsonString) and Assigned(J.Get('last_sql_columnwidth'))) then
    raise Exception.CreateFmt('Fehler beim Laden der Datei (Item %d)', [J.Size]);

  S := J.Get(ValueName).JsonValue.Value;  // Dieses .Value ist natürlich leer, darum oben auch .JsonValue.Value
  ...
finally
  J.Free;
end;

Der Code, wie er schön aussähr, aber nicht funktioniert:

Delphi-Quellcode:

J := TJSONObject.Create;
try
  J.AddPair(...);
  ...
  TFile.WriteAllText(Datei, J.ToString, TEncoding.UTF8);
finally
  J.Free;
end;

J := TJSONObject.ParseJSONValue(TFile.ReadAllText(Datei)) as TJSONObject;
try
  S := J.Get(ValueName).Value;
  ...
finally
  J.Free;
end;

[Der schöne Günther]

Delphi-Quellcode:

try
  (Gedöns)
except
  // Gibt schlimmeres
end;

:-D

[MaBuSE]

Zitat:

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

Delphi-Quellcode:

// Gibt schlimmeres

Ja, eine Abmahnung zum Beispiel !

Ich hatte mal ein mittelgroßes Projekt (ca. 200 Forms) übernommen, bei dem das grundsätzlich so gemacht wurde.
Die Anwender hatten sich daran gewöhnt nach einer durchgeführten Aktion noch mal zu prüfen ob es geklappt hatte.

Die Mitarbeiter in der Abteilung wunderten sich nur, warum immer wieder falsche, unvollständige oder defekte Datenbankeinträge da waren.
Da wurde jeden Tag auf der Datenbank "repariert".

Als ich das Projekt übernahm, habe ich alle

Delphi-Quellcode:

except end;

gesucht und entfernt.

Ergebnis:
Die Anwendung war unbenutzbar. Im Sekundentakt sind Fehlermeldungen aufgetreten.
Bei jedem Create eines Formulars ist eine GPF aufgetreten. (Fehler in der Basisklasse)
Viele Copy & Pase Fehler. (Ein Mal falsch gemacht und immer wieder kopiert.)

Durch einige einfache Suchen & Ersetzen Aktionen waren mehrere 100 Fehler weg.

Die Anwender mussten umlernen. Keine Fehlermeldung = hat geklappt.
Dafür gabs ab und zu Fehlermeldungen, die automatisch geloggt und abgearbeitet wurden.
Nach ein paar Monaten war es dann "fehlerfrei".

Und 2 Leute arbeitslos, da sie nicht mehr den ganzen Tag die Datenbank reparieren mussten ;-)

Ich hasse Programmierer die so was verwenden :evil:

Delphi-Quellcode:

try
  ...
except
end;

FixInsight mahnt das zum Glück an.

Ich empfehle immer nur den "erwarteten" Fehler zu prüfen. Es kann ja immer etwas unerwartetes passieren ;-)

Delphi-Quellcode:

// Zahl in Value in MeinObjekt.IntegerProperty ablegen
procedure Beispiel(const Value: string);
begin
  try
    MeinObjekt.IntegerProperty := StrToInt(Value);
  except
    // Fehlerbehandlung wegen 'Zwei ist kein gültiger Integerwert.'
  end;
end;

...

begin
  Beispiel('Zwei');
end;

In unterem Beispiel wird ein String einer Integer Eigenschaft eines Objekts zugewiesen.
Der Programmierer hat daran gedacht, dass auch ungültige Zahlen wie z.B. "zwei" übergeben werden können.
Aber er geht davon aus , das MeinObjekt immer existiert. Was wenn MeinObjekt = Nil ist?
Das Beispiel unten würde dann zumindest eine Exception (oder GPF) werfen.

Delphi-Quellcode:

// Zahl in Value in MeinObjekt.IntegerProperty ablegen
procedure Beispiel(const Value: string);
begin
  try
    MeinObjekt.IntegerProperty := StrToInt(Value);
  except
    on E: EConvertError do
    begin
      // Fehlerbehandlung wegen 'Zwei ist kein gültiger Integerwert.'
    end;
  end;
end;

...

begin
  Beispiel('Zwei');
end;

[himitsu]

TryStrToInt :stupid:

Nacholgendes ist Beides das Gleiche,
auch wenn es kein schöner Code ist, außer da kommt wirklich "ständig" irgendwelcher Schrott, der aber niemanden interessiert.

Delphi-Quellcode:

i := StrToIntDef(S, 0);

try
  i := StrToInt(S);
except
  i := 0;  // S ist kein Integer
end;

Aber beim Debuggen wirst du schnell den Schuldigen erwürgen wollen, welcher Letzeres genommen hat, voallem wenn diese Funktion im Minutentakt mit Nichtintegern ausgeführt wird.

[Sherlock]

Oh, nichts überbietet ein gepflegtes

Delphi-Quellcode:

begin
  try
.
.
.
    Application.Run;
  except
  end;

end.

in der dpr...

:wall:

Sherlock

[freimatz]

Nach dem "-->"

Code:

procedure TIsoPositionCmdTest.Test_InitData_CharacteristicID();
begin
  m_ReferenceSystemInformationServiceMock.SetFunctionResult<referenceSystemCaseET>('DetermineReferenceSystemCase',
    rsc11EC);
  m_ReferenceSystemInformationServiceMock.SetFunctionResult<TOrientationSet>
    ('AvailableToleranceZoneOrientationKinds', []);
  m_ReferenceSystemInformationServiceMock.SetFunctionResult<TSourceElementsKindSet>
    ('AvailableToleranceZoneOrientationSources', []);

  { Puh: Mit dieser Zeile bringt man Wissen um die Implementiereung in den Test. Auch wenn von der Implementierung,
    von welcher hier die Rede ist, am Besten niemand etwas wüsste ;-).
    Der Test hier will eigentlich nur herausfinden, ob das richtige Element aus den beiden Elementfenstern für das
    zu tolerierende Element herangezogen wird. Diese Logik ist allerdings im InitData gut versteckt und eingebettet,
    so dass auch der Test dazu InitData aufrufen muss. 
--> InitData ist nun aber einer der schlimmsten Orte auf Erden. Das Ungemach, welches einem dort begegnen kann, 
    ist zu düster und umfangreich um es hier detailliert aufzuzeigen.
    InitData startet auch die Berechnung. Man versucht es zwar über ValidForCalculation zu verhindern, aber auch diese
    Methode ist unzureichend implementiert. Man geht dann aber wenigstens davon aus, dass dann das Merkmal in seinem
    Calculate schon jammert wenn was nicht passt. Würde es auch tun. Allerdings bedient sich das Positionsmerkmal dazu
    eines Services und der Success jenes Calculate ist im SetUpMocks mit true intialisiert. Darf halt nicht sein und
    deswegen hier das umstellen auf false.}
  m_ReferenceSystemGeneratorServiceMock.SetFunctionResult<IReferenceSystemCalculationResult>('Calculate',
    CreateReferenceSystemCalculationResult(false, identityMat4C, identityMat4C, '', sraUndefinedEC));

  Self.InitStatusDatabaseWithIdsAndDelegate('Kr1', 'Zyl1');
  CheckInitDataCharacteristicID();
end;

[Mavarik]

Zitat:

Zitat von MaBuSE (Beitrag 1376404)

Delphi-Quellcode:

try
  ...
except
end;

Ich empfehle immer nur den "erwarteten" Fehler zu prüfen. Es kann ja immer etwas unerwartetes passieren ;-)

Delphi-Quellcode:

// Zahl in Value in MeinObjekt.IntegerProperty ablegen
procedure Beispiel(const Value: string);
begin
  try
    MeinObjekt.IntegerProperty := StrToInt(Value);
  except
    // Fehlerbehandlung wegen 'Zwei ist kein gültiger Integerwert.'
  end;
end;

...

begin
  Beispiel('Zwei');
end;

Unter dem Strich hast Du natürlich zu 100% Recht. Also gibt es "eigentlich" nix was man hierzu erwidern kann, oder?

Die eigentlich Frage lautet : Was ist Dir wichtiger...?

Beispiel :

Gegeben sein eine Software die bei 5000 Kunden im Einsatz ist.
Gegeben sein eine Routine die bei diesen Kunden jeden Tag 100 Briefe ausdruckt...

Es gibt ein Softwareupdate das im Footer die Seitenanzahl ausgeben kann. In diese Routine hat sich ein Fehler eingeschlichen.

Dadurch wird die Seitenzahl nicht eingedruckt. Der try except end Abfänger verhindert eine Fehlermeldung...

Status : Alle Kunden sind glücklich - alle Briefe wurde gedruckt. Alle können "fehlerfrei" arbeiten!

Bei jedem Kunden 100x pro Tag ein Exception Fenster. Ist keine Option. Das würde nur die Hotline überlasten.
Von jeder Exception eine E-Mail (500.000 Stk.) ist auch keine Option.

Dann doch lieber einen Anruf von einem Kunden oder zwei (mehr merken es nicht, weil keiner die Neuerungsliste gelesen hat) der mitteilt, dass die Seitenzahl fehlt...

Also so pauschal kann man also doch nicht sagen ein "Try Except End" ist immer böse...

Gut, die Qualitätskontrolle hat versagt...

Aber wer hat schon für so etwas ein Test-Team oder einen Unittest - 30 Jahre alter Software? :twisted:

Positiver Nebeneffekt - Die Kunden sagen: "Das ein oder andere Funktioniert noch nicht, aber dafür gibt es keine Exceptions in der Software..."

Mavarik

PS.: Oje... was werde ich dafür wieder an Kommentaren ernten..

[himitsu]

Es geht vorallem um die leeren Try-Except, also wo im Fehlerfall rein garnichts gemacht wird, bzw. wo der Fehler fahrlässig nicht/falsch behandelt wird.

Fehler abfangen und loggen ist auch eine Behandlung.



zu deinem Beispiel:
* fehlt nur die Seitenzahl, aber das dokument kommt raus, dann isses OK
* wird dennoch die "Zahl" geschrieben, aber mit einem falschen Wert, dann wird es schon problematischer
* wird garnichts mehr gedruckt, andere Teile fehlen im Ausdruck oder sind dadurch falsch, dann wäre es nicht nett, wenn der User die Fehlermeldung nicht bekommt

[JasonDX]

Ich würde zudem argumentieren dass die Qualitätsprüfung insb. dann fehlschlägt, wenn kein offensichtlicher Fehler auftritt. Wenn denen eine Exception um die Ohren fliegt, wird das Update nicht rausgehen. Weil aber Fehler geschluckt werden, sind Kleinigkeiten falsch die den Testern nicht auffallen, und der Kunde bekommt die Bananensoftware zum selbertesten.
Aber gut, jeder darf selbst die Qualität seiner Software bestimmen.


(was schreibst du dann eigentlich in deine Patch-/Update-Beschreibungen? "Druckt Seitenanzahl - vielleicht"?)

[MaBuSE]

Zitat:

Zitat von Mavarik (Beitrag 1376465)

Unter dem Strich hast Du natürlich zu 100% Recht. Also gibt es "eigentlich" nix was man hierzu erwidern kann

Das lass ich jetzt mal so stehen ;)

Zitat:

Zitat von Mavarik (Beitrag 1376465)

Die eigentlich Frage lautet : Was ist Dir wichtiger...?
...
Es gibt ein Softwareupdate das im Footer die Seitenanzahl ausgeben kann. In diese Routine hat sich ein Fehler eingeschlichen.
Dadurch wird die Seitenzahl nicht eingedruckt. Der try except end Abfänger verhindert eine Fehlermeldung...

Mir wäre wichtiger, dass der Fehler schnellstmöglich gefunden und behoben wird, statt dass sich viele nicht gefundene Fehler anhäufen und nie von dem Entwickler behoben werden, da er nichts davon weiß.

Wenn Du nicht in der Lage bist Deine Software (wenigstens einigermaßen) zu testen, solltest Du von Deinen 5000 Kunden 25 fragen, ob sie an einen Beta Test teilnehmen möchten.
Im Beta Test kannst du schnell neue Versionen ausrollen und die Kunden sind oft dankbar, das sie schon die neuen Funktionen nutzen können.

Langfristig hast Du aber viel mehr zufriedene Kunden (, bei denen die Seitenzahlen richtig geduckt werden;)
Und diese Kunden haben dann auch zufriedene Kunden, da auf ihren Schreiben keine falschen Seitenzahlen gedruckt wurden. ;)


Verstehe mich nicht falsch. Es spricht nichts dagegen Fehler zu klassifizieren und "unwichtige" Fehler "nur" zu loggen und den Anwender nicht damit zu belästigen.
Aber durch das fehlende

Delphi-Quellcode:

on E: Fehlerklasse

oder das böse

Delphi-Quellcode:

try ... except end;

darauf zu verzichten nicht klassifizierte also unbekannte Fehler zu entdecken, finde ich fraglich.

Ich möchte beim Autofahren auch erfahren, wenn ein unbekanntes Problem bei meinen Bremsen auftritt.
Unwichtige "bekannte" also klassifizierte Fehler interessieren mich hingegen nicht.
Das erwarte ich von den Programmierern der Software in meinem Auto.

[Mavarik]

Zitat:

Zitat von MaBuSE (Beitrag 1376471)

Ich möchte beim Autofahren auch erfahren, wenn ein unbekanntes Problem bei meinen Bremsen auftritt.
Unwichtige "bekannte" also klassifizierte Fehler interessieren mich hingegen nicht.

Möchtest Du auch, dass durch einen Fehler im "Bremsen Sensor abfrage Programm" Dein Auto jedes mal stehen bleibt und der Motor aus geht?

Nee, Spaß beiseite - schon klar worum es Dir geht... (Ist auch der falsche Thread für diese Diskussion)

[MaBuSE]

Zitat:

Zitat von Mavarik (Beitrag 1376472)

Nee, Spaß beiseite - schon klar worum es Dir geht... (Ist auch der falsche Thread für diese Diskussion)

Jetzt kannich schreiben:
Unter dem Strich hast Du natürlich zu 100% Recht. Also gibt es "eigentlich" nix was man hierzu erwidern kann

[MaBuSE]

Zitat:

Zitat von Relicted (Beitrag 652789)

Delphi-Quellcode:

  //...
  except
    // Fehler nur schlucken!
    // Anmerkung: JAAAAA SCHLUCK DU LUDER :-))
  end;

Das war übrigens aus dem 1. Beitrag in diesem Thema ;)

[edit]
In 9 Tagen ist das 10 Jahre her !!!
Der 1. Beitrag in diesem Thema ist vom 20. Jul 2007
[/edit]

[Der schöne Günther]

Zitat:

Zitat von Mavarik (Beitrag 1376472)

Möchtest Du auch, dass durch einen Fehler im "Bremsen Sensor abfrage Programm" Dein Auto jedes mal stehen bleibt und der Motor aus geht?

Ja !?! :shock:

Delphi-Quellcode:

try
   if benutzerMöchteBremsen() then
      zieheBremsenAn();
except
   // Gibt schlimmeres
end;

[himitsu]

Delphi-Quellcode:

if BenutzerMöchteBremsen then
  ZieheBremsenAn;
// wenn's nicht klappt ... k.A. was passiert, aber der Benutzer bekommt wenigstens erstmal sofort mit, daß jetzt doch nicht gebremst wird und kann anders drauf reagieren (rausspringen)


try
  if BenutzerMöchteBremsen then
    ZieheBremsenAn;
except
  NotfallAnhalteProzedur;  // Anker abwerfen
end;

Das Microsoft-Auto der Zukunft: "Ein Unfall wurde erkannt, wollen sie, dass der Airbag jetzt auf geht?"

[Luckie]

Ihr werdet offtopic! Bitte diskutiert die Fehlerbehandlung mit try-ecept in einem eigenständigen Thread.

[Der schöne Günther]

Irgendwie liest sich

Delphi-Quellcode:

(...)
   else
      Result := Succ(self);

schon etwas komisch :dance:

[Glados]

Das ist zwar kein Kommentar, aber auch nicht schlecht:

Delphi-Quellcode:

ShowMessage('Ups! An error occured!' + sLineBreak + 'The developer didn''t remove some obsolete code.' + sLineBreak + 'Maybe you let him know about this mistake? =)');

[himitsu]

ShowMessage-Fehlerbehandlung?

Delphi-Quellcode:

raise EProgrammerNotFound.Create('Ups! An error occured!' + sLineBreak + 'The developer didn''t remove some obsolete code.' + sLineBreak + 'Maybe you let him know about this mistake? =)');

Wenn Delphi schon einen passenden Typ mitbringt, dann wäre es doch schön, wenn er öfters auch benutzt wird. (ich hab auch das Gefühl, dass Viele ihn nichtmal kennen)



Ich hatte auch mal 'nen Code in unserem Programm, der sah etwa so aus

Delphi-Quellcode:

else
  raise EProgrammerNotFound.Create('Das sollte eigentlich niemand sehen, ....');

Nja, es sah dann doch einer der Kunden und guckte nicht schlecht.
Bei einem späteren Umbau wurde was vergessen und es sprang dann doch da rein, nach nichtmal 3 Monaten.

[Glados]

Zitat:

ShowMessage-Fehlerbehandlung?

Ist eigentlich nur ein Witz :P
Der Code steht in einer Unit die ich nicht mehr verwende.

Bzgl EProgrammerNotFound
https://stackoverflow.com/questions/...tion-in-delphi

[Daniel]

// glauben wir an das gute - bis wir es mal wieder besser wissen

:-)
Läuft übrigens seit Jahren. Eine Portion Zuversicht scheint nie verkehrt zu sein.

[Codehunter]

Auch wenn es nicht gerade Kommentare sind: Die meisten größeren Projekte haben bei mir eine Art Kernel-Klasse. Die heißt manchmal TNexus, manchmal TNebula und in einem Fall TTasse.

[himitsu]

Das nennt selbstkommentierenden Code.

[Stevie]

Zitat:

Zitat von Codehunter (Beitrag 1377827)

Auch wenn es nicht gerade Kommentare sind: Die meisten größeren Projekte haben bei mir eine Art Kernel-Klasse. Die heißt manchmal TNexus, manchmal TNebula und in einem Fall TTasse.

So etwas?

[bcvs]

Delphi-Quellcode:

  
try
  pi:=Printer.PrinterIndex;  // Drucker installiert?
  MachWasSinnlosesMit(pi);   // Warnung unterdrücken H2077 Auf 'pi' zugewiesener Wert wird niemals benutzt
except
  on EPrinter do begin
  //..
  end;
end;

Ich weiß, man könnte auch einfach nur

Delphi-Quellcode:

Printer.PrinterIndex;

aufrufen und den Rückgabewert ignorieren.

[himitsu]

Was Sinnloses Nutloses mit PI, denn der Compilier ist nicht schlau genug, um zu erkennen, das hier nichts gemacht wird:

Delphi-Quellcode:

if pi = 0 then ;

oder ohne Variable

Delphi-Quellcode:

try 
  if Printer.PrinterIndex < 0 then 
    raise Exception.Create('nö');
except
  ...

Sinnlos finde ich aber den Kommentar am TThread.ForceQueue.
Man hätte auch das Queue direkt reparieren können und wenn man mag, dem einen Parameter

Delphi-Quellcode:

WennDuWillstDannEbenDochSofortFallsImHauptthread: Boolean=False;

verpassen. :wall:

[Blup]

Nachdem wiederholte "Optimierungsversuche" eines Kollegen an dieser Stelle zu überraschend zeitaufwendiger Fehlersuche geführt haben:

Delphi-Quellcode:

begin
  {!!!hier nicht ändern!!!}
  ...

[Codehunter]

Zitat:

Zitat von Stevie (Beitrag 1377844)

Zitat:

Zitat von Codehunter (Beitrag 1377827)

Auch wenn es nicht gerade Kommentare sind: Die meisten größeren Projekte haben bei mir eine Art Kernel-Klasse. Die heißt manchmal TNexus, manchmal TNebula und in einem Fall TTasse.

So etwas?

Lach nein. Da könnte ich ja gleich ein Konsolenprogramm schreiben und TMyClass drumrum setzen ^^ Die Kernel kann man nicht mit dem vergleichen was man z.B. bei Windows so nennt. Die kümmern sich i.d.R. in Tabbed-MDI um die Fensterverwaltung und deren Kommunikation untereinander.

[Der schöne Günther]

Message für Merge-Commit: Ab jetzt hilft nur noch beten...

[dummzeuch]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1311958)

Zitat:

Zitat von Sherlock (Beitrag 1311952)

In XE8 ist das ja bestimmt behoben worden.

Nö. Schaut genauso aus

In 10.2.2 übrigens immernoch.

[Fukiszo]

Delphi-Quellcode:

//[07/05/09 - 21:07] [#62] Du magst ja Herausforderungen, hier ist eine aber ich erhalte immer Access Violations (dll<>programm)
//[07/05/09 - 23:12] [#7]  wieso alles so verschachtelt bis zum getno, nochma von vorn mit mehr struktur ---kotz und danke für die arbeit
//[07/05/09 - 23:51] [#7]  -> fertig & lass deine hände davon, gucken erlaubt -> anfassen NEIN

beim durchstöbern entdeckt (:

[Codehunter]

Es ist nicht direkt ein Quellcode-Kommentar, sondern mehr ein kleines Easteregg:

Vor vielen vielen Jahren gab es mal ein schrecklich kompliziertes Matlab-GUI, mit GUIDE gebaut. Auf einem Form lagen diverse Groupboxes mit unterschiedlichen Bedeutungen. In jeder Groupbox gab es einen Button zum Laden einer Binärdatei mit der Caption "Bin Laden" (in genau dieser Schreibweise). Der Komponentenname hieß logischerweise "Osama1", "Osama2" usw. Hielt mal STRG-SHIFT-ALT gedrückt beim Anklicken, versteckte sich ein kleiner Taliban in den "Bergen", die auf einer Graphenausgabe gezeichnet wurden. Im Falle eines visualisierten Übersteuerns der Kurve, also Fehlerfall, sprang der kleine Bösewicht hervor. Ich glaube, das Programm wurde in der Form viele Jahre an die Anwender ausgeliefert ^^

[Benedikt Magnus]

Delphi-Quellcode:

procedure TSpielerMensch.SpielFortfahren; override;
begin
  //Der Mensch sieht das selbst.
end;

[freimatz]

Heute darübergestolpert (ßßß von mir ersetzt)

Delphi-Quellcode:

unit ßßß;
{******************************************************************************
  PROJECT    : ßßß
  SUBPROJECT : ßßß
 .............................................................................
  DESCRIPTION:
    Contains DTOs (Data Transfer Objects) for carriage manager testautomation services. All DTOs
    contain are fields of data - there is no logic implemented in here. I did my best
    to prevent 'mistakes' of this sort, but please please do not implement logic in the
    DTOs.

    ---- WARNING ---- WARNING ---- WARNING ---- WARNING ---- WARNING ---- WARNING ---- WARNING ---- WARNING ----
    *************************************************************************************************************
    *  If you want to use the Embarcadero JSON classes, there is one braindead implementation                   *
    *  detail you NEED to know about, before implementing your classes. They absolutely require                 *
    *  your fields to be in the form:                                                                           *
    *                                                                                                           *
    *    FSomeField : String;                                                                                   *
    *    property SomeField : String read FSomeField write FSomeFields;                                         *
    *                                                                                                           *
    *  The reason for this is that they hardcoded add a 'F' character to the field names coming in from         *
    *  JSON. So if the JSON code says the field's name is 'foobar', they change that to 'Ffoobar', without      *
    *  any checks, without any choice, without any error message if (when) that braindead hack kills inter-     *
    *  operability. Anything not in that form (for example a member variable called m_something) will NOT       *
    *  be reconstituted back into the object, even though the parser DOES find the field in the JSON code,      *
    *  since THAT TOO WILL BE RENAMED to Fm_something! They do NOT check whether a field is a property before   *
    *  messing up the name! Furthermore, subsequent calls of serialization / deserializatoin lead to field      *
    *  names like FFFFFMyField. So please, just follow embarcadero's religion about how field names gotta       *
    *  look.                                                                                                    *
    *                                                                                                           *
    *  This is literally the worst JSON implementation I've ever seen and shows the complete lack of skill of   *
    *  embarcadero's 'engineers'.  -- ßßß                                                                       *
    *                                                                                                           *
    *************************************************************************************************************

    If you want to see where that hack is located, it's in the unit REST.JsonReflect, the function
    TJSONUnMarshal.ConvertFieldNameFromJson starting at line 2446 ff.
}

interface

[Der schöne Günther]

Wahnsinn wie dieses blödsinnige F-Prefix die Emotionen immer wieder hochkochen lässt.

Natürlich auch hier.

Zitat:

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

Fest einkodiert. All mein Hass. Ganz ehrlich... :kotz:

Zitat:

Zitat von Dejan Vu (Beitrag 1274461)

Was für ein Dreck. […]
'Teeren und Federn' war zu meiner Zeit das adäquate Mittel, den Programmierer für derartige Ergüsse öffentlich zu würdigen.

[Codehunter]

Ist halt ein Pseudostandard, so wie Ereignisse immer mit einem "On" beginnen sollten, aber auch nicht immer tun in der VCL. Letztlich sollte man einfach konsequent bei einem Stil bleiben. Besonders im Team. Ich finde nichts schlimmer als Code, den nur der Autor lesen kann.

[himitsu]

Zitat:

Zitat von Codehunter (Beitrag 1406696)

Code, den nur der Autor lesen kann.

Der ist damit aber unkündbar. :stupid:

[p80286]

"Ich weiß, Sie sind unersetzlich, aber ich liebe Herausforderungen."

Gruß
K-H

[MaBuSE]

Zitat:

Zitat von himitsu (Beitrag 1406711)

Zitat:

Zitat von Codehunter (Beitrag 1406696)

Code, den nur der Autor lesen kann.

Der ist damit aber unkündbar. :stupid:

Da muss ich immer an die Titelmelodie von Tom und Jerry denken:

Zitat:

Zitat von Udo Jürgens, Lied: Vielen Dank für die Blumen

Als Mann der Tat ist man beim Chef gut angeschrieben
Da machte ich mich an die Sekretärin ran
Ich tat mein Möglichstes und hab' wohl übertrieben
Denn im Betrieb da ist der Chef der erste Mann

Er bat mich zu sich und er sagte, „Sie verstehen wohl
Es wäre schrecklich, wenn wir Sie bei uns verlieren
Ich weiß auch nicht wie's ohne Sie hier weiter gehen soll
Doch wollen wir das ab nächsten ersten mal probieren“

Vielen Dank für die Blumen
Vielen Dank, wie lieb von dir

...