Variablen in Stringliteral inlinen

[dummzeuch]

Zitat von Uwe Raabe:

Zitat von freimatz:

Hm, mir kommt gerade eh der Gedanke, dass Texte eigentlich gar nicht in Code gehören.

Umgekehrt gehört Code (hier Variablennamen) auch nicht in String-Literale.

+1

Wobei das eigentlich auch für die Platzhalter in Format-Strings gilt. Wenn der Übersetzer dabei einen Fehler macht, stürzt das Programm ab:

 s := Format(_('Result is %d'), [Res]);
Und der Übersetzer vertippt sich:
'Ergebnis ist %f'

Bumm!

[himitsu]

Zitat von dummzeuch:

Und der Übersetzer vertippt sich:
'Ergebnis ist %f'
Bumm!

Texte mit Formatierungen aus anderen Quellen sind immer nett, wenn das Programm plötzlich verreckt.
(Übersetzung/Datenbank wo Texte durch user bearbeitet oder über eine Synchronisierung/Update nachgeladen werden)

Drum hab ich bei uns das Format überschrieben/überdeckt.
Der Code muß nur in eine Unit die immer nach den SysUtils eingebunden wird.

Wenigstens "etwas" anzeigen und das Programm nicht abkratzen lassen.

Delphi-Quellcode:

function Format(const FormatStr: string; const Args: array of const): string;
begin
  try
    Result := SysUtils.Format(FormatStr, Args);
  except
    {Meldung ins Log, wenn sowas vorhanden}
    Result := FormatStr;  // oder Result := '[ERR] ' + FormatStr; 
  end;
end;

Oder zumindestens dem Entwickler etwas helfen, damit man gleich sieht bei welchem "kompletten" String es knallt.

Delphi-Quellcode:

function Format(const FormatStr: string; const Args: array of const): string;
begin
  try
    Result := SysUtils.Format(FormatStr, Args);
  except
    on E: Exception do begin
      E.Message := 'Fehler in Format-String >>' + FormatStr + '<<' + sLineBreak + sLineBreak + E.Message;
      raise;
    end;
  end;
end;

Und das Gleiche für die Variante mit den FormatSettings.

Alternativ verwendet man niemals Format, sondern ruft eine eigene MyFormat auf.

[Uwe Raabe]

Zitat von dummzeuch:

Wenn der Übersetzer dabei einen Fehler macht, stürzt das Programm ab

Da braucht er nicht mal einen Fehler machen. Es genügt, wenn er den Satzbau umstellt und sich dadurch die Reihenfolge der Parameter ändert. Deswegen sollte man in solchen Fällen auf die Index-Funktionalität in Format zurückgreifen.

[himitsu]

Joar, oder automatische Übersetzer, die z.B. ein "%s" trennen.
In "% s" oder die beiden wild verteilen, bzw. Teile weglassen.

Hatte mal mit Poedit gespielt und dort eine automatische Google-Translate-Übersetzung reingeladen.
Da kamen die wildesten Ergebnisse bei raus.

Oder bei einigen Online-Spielen gibt es z.B. im Chat/Mails eine automatische Üersetzung, wo bei Systemnachrichten die Platzhalter gern mal zerstört werden.

[dummzeuch]

Zitat von himitsu:

Texte mit Formatierungen aus anderen Quellen sind immer nett, wenn das Programm plötzlich verreckt.
(Übersetzung/Datenbank wo Texte durch user bearbeitet oder über eine Synchronisierung/Update nachgeladen werden)

Drum hab ich bei uns das Format überschrieben/überdeckt.
Der Code muß nur in eine Unit die immer nach den SysUtils eingebunden wird.

Wenigstens "etwas" anzeigen und das Programm nicht abkratzen lassen.

Wir gehen bei unseren Programmen noch einen Schritt weiter und installieren einen Hook für die Format-Funktion. Das passiert in einer Unit, die automatisch in allen unseren Programmen eingebunden wir. Dann wird sowas auch für fremden Code abgefangen. Und man kann man muss auch nicht daran denken, überall eine solche Unit einzubinden.

Am meisten nervt mich aber, dass man den Datentyp überhaupt angeben muss. Write kann den ja auch automatisch erkennen, warum gibt es bei Format nicht sowas wie einen generischen Platzhalter:

Format('Der Wert ist %g', [IrgendeineVariable]);

Die Format-Funktion weiss ja, welcher Datentyp übergeben wurde, denn eigentlich ist das ja ein Variant mit entsprechenden Informationen. Den kann man dann halt nach String konvertieren. Für viele Anwendungen würde das ausreichen.

Aber das Thema war ja ein anderes ...

[Luckie]

Und woher soll write wissen, wie viele Nachkommastellen du willst? Wie viele führende Nullen?

[Poelser]

Moin,

da wäre so etwas wie die Systemeinstellungen für das Datumsformat denkbar. Wenn der Entwickler das anders haben will, dann könnte er die Formatanweisungen wie bisher benutzen.

Bis denne,
Edmund

[Stevie]

Zitat von dummzeuch:

Die Format-Funktion weiss ja, welcher Datentyp übergeben wurde, denn eigentlich ist das ja ein Variant mit entsprechenden Informationen.

Falsch! Es ist ein TVarRec - und die haben ebend nicht genügend Informationen über den Typen.

Hab erst gestern geschaut, ob man Format so umbauen könnte wie string.Format in .NET, die dort übergebenen Parameter sind alle object und haben somit die exakten Typeninformationen dabei.
Mit SysUtils.Format kann ich nichtmal Datum oder Zeit allein über den Formatstring ausgeben

Zitat von Luckie:

Und woher soll write wissen, wie viele Nachkommastellen du willst? Wie viele führende Nullen?

Indem man es angibt - das erfordert aber nicht die grundsätzliche Angabe des Typens - siehe string.Format

Übrigens solltet ihr nicht Write und Format verwechseln, die funktionieren unterschiedlich.

[Luckie]

Ich meine natürlich Format. Sorry.

[himitsu]

Zitat von dummzeuch:

Wir gehen bei unseren Programmen noch einen Schritt weiter und installieren einen Hook für die Format-Funktion.

Wir arbeiten viel mit Packages und DLLs.
Eine große Hook-Engine wollte/konnte ich für die paar Kleinigkeiten nicht so einfach integrieren. (die das dann je nach Ziel richtig erledigt)
Und beim selbst hooken (JMP+Adresse in Prozeduranfang schreiben oder bei Packages/DLL in "allen" Libraries die Referenz überschreiben) muß man da bissl aufpassen, dass man den hook nicht nur im aktuellen Package/DLL macht (war mir einmal passiert (vorsicht vor Copy&Paste aus Hook-Tutorials, denn die sind fast immer nur für Ein-EXE-Anwendungen) und ob man dann die originale Funktion auch noch verwenden möchte und demnach eben nicht den Prozeduranfang überschreiben kann.