[gelöst] Name der aktuellen Prozedur als String

[marcov]

Der echte WFT ist aber, dass jemand die Syntax für Include-Files überladen hat... {$I %

So abwegig finde ich das nicht. {$I ...} meint "füge Quellcode ein", entweder aus einer Datei oder aus einer internen Quelle mit "%...%".

%% war der originelle Syntax für Enviroment Variablen glaube ich. Aber das ist schon Syntax von bevor 1.0 denk ich so.

Mit Delphi Kompatibilität hat das nichts zu machen, dies war schon da in 1.0.0 und nicht TP oder Delphi kompatibel.

[Mathias]

{$I %FILENAME%}
{$I %LINE%}
{$i %DATE%}
{$i %TIME%}
{$I %CURRENTROUTINE%}

Gibt es irgendwo ein Auflistung alle dieser Befehle ?
{$I %FILENAME%} hat er bei mir nicht geschluckt.

[wp_xyz]

http://www.freepascal.org/docs-html/prog/progsu41.html

[Michl]

Warum schreibt man hier nicht einfach "Button1Click" statt "{$I %CURRENTROUTINE%}"?

Meistens hat man ein festes Prologe und Epiloge zu einen Prozedur/Methode. Die können komplizierter sein, und werden also oft rund kopiert. Damit ist es ein Risiko das die Namen nicht korrigiert werden.

+1 - Genau mein Problem.

Ich habe gerade mal zusammengezählt. Mein Projekt, in dem ich den Log nutze, ist kurz vor 120.000 Zeilen Code. Wobei ich schätze, dass evtl. 5% für den Log, Infos und Exceptionbehandlung genutzt werden.
Zurzeit nutze ich Code Templates und bin recht zufrieden damit. Mit diesen ist bei der Erstellung einer neuer Methode nur eine Tastenkombination erforderlich und schwupps sind die kompletten Logmethoden eingefügt.
Das was jetzt nachträglich unnötige Arbeit macht ist, daß wenn ich etwas umstelle, z.B. einen neuen besseren Bezeichner wähle, ich sämtliche Log-Texte per Hand durchgehen und den Bezeichner ändern muss (bei 6.000 möglichen Zeilen verbrät man dafür ganz schön Zeit).

Dass es nun die Möglichkeit gibt, den Bezeichner per Compiler einfügen zu lassen, finde ich gut. Werde ich bestimmt in Zukunft auch so nutzen. Daher danke dafür

[Patito]

Code runnt nicht immer im Debugger. Dann kommt Logging im Einsatz.

Dazu gibt es sinnvolle Fehler- und Log-Messages. Prozedurnamen sind für sowas denkbar schlecht geeignet.
Wenn man es mit Logdateien zu tun hat, will man klar erkennbare Meldungen, die man auch vollautomatisch
auswerten kann... und nicht etwas, das sich in jeder Version beliebig ändern kann.

Außerdem gehören Debug-Informationen traditionellerweise nicht in eine Release-Anwendung - die Leute wollen
normalerweise nicht, dass man den Code einfach reverseengineert.

Ein guter Sprach-Designer baut keine Spezialsyntax ein, die in fragwürdigen Sonderfällen Tipparbeit sparen. Solange
ihr nur Rand-Features ändert könnt ihr nicht viel kaputt machen. Wenn ihr euch mal was großes vornehmt, steht
hoffentlich MSELang oder jemand anderes bereit.

[marcov]

Code runnt nicht immer im Debugger. Dann kommt Logging im Einsatz.

Dazu gibt es sinnvolle Fehler- und Log-Messages. Prozedurnamen sind für sowas denkbar schlecht geeignet.

Das ist reine Geschmack. Prozedur Namen machen es einfach Code zu finden, und haben auch (fuer Programmierer) freundliche Namen (also besser als src.pas:1234)

Wenn man es mit Logdateien zu tun hat, will man klar erkennbare Meldungen, die man auch vollautomatisch
auswerten kann... und nicht etwas, das sich in jeder Version beliebig ändern kann.

Es gibt keine Strategie die in alle Fälle gut ist. (No Silver Bullet). Software Development hängt davon ab das man die Mittel proportional einsetzt zum Ziel. Log Systemen so ausreifen ist nicht immer sinnvoll (overengineering).

Nur in die Akademie werden Problemen top-down zum letzten Detail ausgearbeitet. In Wirklichkeit hat man dazu nicht die Zeit, und man hat auch nicht das totaler Übersicht und alle Anforderungen bevor man startet.

Außerdem gehören Debug-Informationen traditionellerweise nicht in eine Release-Anwendung - die Leute wollen
normalerweise nicht, dass man den Code einfach reverseengineert.

Man will auch nicht das ein Kunde ein Problem anmeldet, und man gar kein Idee hat wo anzufangen zu suchen.

Ein guter Sprach-Designer baut keine Spezialsyntax ein, die in fragwürdigen Sonderfällen Tipparbeit sparen. Solange
ihr nur Rand-Features ändert könnt ihr nicht viel kaputt machen. Wenn ihr euch mal was großes vornehmt, steht
hoffentlich MSELang oder jemand anderes bereit.

Und Sprachen micromanagen auf Grund puristischer Idealen gehört ganz in die Akademien zu hause.

P.s. apropos MSELang, ich glaube nicht darin. Der Trend ist weniger sprachen, nicht mehr, und das Reinheitsgebot in Sprachen ist schon zeit 2000 altmodisch.

[Patito]

Ein guter Sprach-Designer baut keine Spezialsyntax ein, die in fragwürdigen Sonderfällen Tipparbeit sparen.

Und Sprachen micromanagen auf Grund puristischer Idealen gehört ganz in die Akademien zu hause.

P.s. apropos MSELang, ich glaube nicht darin. Der Trend ist weniger sprachen, nicht mehr, und das Reinheitsgebot in Sprachen ist schon zeit 2000 altmodisch.

Sicher kann man mal ein paar krumme Tricks verwenden, wenn man mal den richtigen Weg nicht findet,
aber dafür mit der Syntax einer Programmier-Sprache rumspielen? Seit 2000 ist eh alles egal... selten so einen Quatsch gehört...

[marcov]

aber dafür mit der Syntax einer Programmier-Sprache rumspielen? Seit 2000 ist eh alles egal... selten so einen Quatsch gehört...

Exhibit A: http://glyphic.s3.amazonaws.com/ozone/m ... 300dpi.jpg