So sehr uns auch Unittests und ähnliche Werkzeuge dabei helfen möglichst fehlerfreien Code zu schreiben, wir kommen bei bestimmten Projektgrößen nicht an Log-Meldungen vorbei um die Arbeitsweise unseres Codes im laufenden Betrieb nachzuvollziehen.

In folgender Funktion sind beispielsweise Start und Ende mit solchen Log-Ausgaben versehen.

function FetchData: TStream;
begin
  WriteLn('Call FetchData...');

  (* ... *)
  (* jede Menge Code *)
  (* ... *)

  WriteLn('FetchData done.');
end;

Wird diese Funktion nun aufgerufen erhalten wir wie erwartet die Ausgaben

Call FetchData...
FetchData done.

Soweit so gut. Aber was passiert, wenn im Rahmen eines Refactorings der Name der Funktion angepasst wird?

Die erste Log-Zeile zum Funktionsbeginn hat unser Entwickler im Blick…

function GetWebdataStream: TStream;
begin
  WriteLn('Call GetWebdataStream...');

  (* ... *)
  (* jede Menge Code *)
  (* ... *)

  WriteLn('FetchData done.');
end;

… die zweite am Ende wurde leider übersehen. Und schon wundert man sich über die Ausgabe.

Call GetWebdataStream...
FetchData done.

Sicherer wäre es, wenn man den Funktionsnamen automatisch in die Log-Ausgabe übernehmen könnte. Und dank der $I-Direktive von FPC kann man das auch.

function GetWebdataStream: TStream;
begin
  WriteLn('Call ', {$I %CURRENTROUTINE%}, '...');

  (* ... *)
  (* jede Menge Code *)
  (* ... *)

  WriteLn({$I %CURRENTROUTINE%}, ' done.');
end; 

Egal wie die Funktion nun heißt, es wird immer der korrekte Funktionsname ausgegeben. Änderungen des Namens erfolgen also nur noch an einer Stelle.

Call GetWebdataStream...
GetWebdataStream done.

Die $I-Direktive kann auch noch mehr.

WriteLn('Call ', {$I %CURRENTROUTINE%}, ' in ', {$I %FILE%}, ' line ', {$I %LINE%}, '...');

Damit erhalten wir dann noch eine detaillierte Log-Ausgabe, die bei der Fehlersuche nützlich ist.

Call GetWebdataStream in webconnector.pas line 155...

Mehr zu dieser Compiler-Direktive findet man in der offiziellen FPC-Dokumentation.