[gelöst] Procedure ohne Var dennoch mit oder ohne '()'?

[mse]

Hm... muss also dann wohl für mich selber entscheiden, wie ich es schreiben will?

Technisch kannst du machen was du willst, wie bereits geschrieben, es geht um Stil/Systematik.
Argumente hast du jetzt ja genug...

[kupferstecher]

Nicht unbedingt Geschmackssache sondern Stil/Systematik. Meiner Meinung nach sollten Codeelemente die das gleiche machen auch immer gleich aussehen. Ein Funktions/Prozedur Aufruf hat zwingend Klammern wenn Parameter übergeben werden sollen, darum sollten auch Aufrufe ohne Parameter mit Klammern geschrieben werden

Die Klammer zeigt an, dass da noch was kommt. Wenn aber nichts mehr kommt, sind die Klammern nicht nur überflüssig, sondern kontraproduktiv, sie stören (meinen) Lesefluss. Das Argument lasse ich also nicht gelten
Dass man aber bei Funktionsaufrufen ohne Parametern mit oder ohne Klammern immer im gleichen Stil bleiben sollte, da stimme ich zu.

um Verwechslungen mit Adressen und Variablen zu vermeiden.

Das ist jetzt ein anderes (berechtigtes) Argument. Aber wie notwendig ist das? Besser man verwendet aussagekräftige Namen. Über Properties ruft man oft Prozeduren/Funktionen auf, die als Variable getarnt sind. Grundsätzlich sollte man aber zu viele Nebenläufigkeiten in einem Ausdruck vermeiden. Daher mag ich auch so ein (eher wieder c-typisches) Konstrukt nicht:

Code: Alles auswählen

if FileDialog.Execute then OpenFile;
//besser
status:= FileDialog.Execute;
if status then OpenFile;
//Noch besser (wenn man die Funktion selber programmiert)
FileDialog.Execute(Status);
if status then OpenFile;

Hier steht die Aktion FileDialog.Execute im Vordergrund und nicht die logische Abfrage. Aber das ist natürlich auch Geschmakssache.

Unter Fortran ruft man Prozeduren über den Befehl "call" auf (unabhängig davon ob es Parameter gibt oder nicht), das finde ich prinzipiell auch nicht schlecht.

Sowas ist schon fehleranfällig:

Code: Alles auswählen

if a = b then
  WritelLn(a);
  WritelLn(b);
Ichmachewas;

Ich halte das den Anforderungen entsprechend flexibel. Ich kann Code besser formatieren wie ein Programm, da ich den Sinn und Zweck meines Codes kenne (meistens). Aber, wenn ich ohne begin..end arbeite, kommt das 'then'- Schlüsselwort immer in die Zeile mit dem Befehl, also:

Code: Alles auswählen

if a = b
then b:= a+1;

Da passiert dann auch nichts. Übrigens genauso bei for..do.

Hier ein Beispiel aus einem tatsächlichen Projekt:

Code: Alles auswählen

procedure TAudioPlayback.Play(Sender: TObject);
begin
  if fPlaying then EXIT;
  if length(AudioData) < 5 then EXIT;
 
  fPlaying:= true;
  DataIndex:= -1;
 
  if assigned(ShowPlaying)
  then TThread.Synchronize(TThread.CurrentThread,ShowPlaying);
 
  StartPlayback;   
 
end;
 

[mse]

um Verwechslungen mit Adressen und Variablen zu vermeiden.

Das ist jetzt ein anderes (berechtigtes) Argument. Aber wie notwendig ist das? Besser man verwendet aussagekräftige Namen.

Hier sind Prozedur/Funktions-Variableninhalte und Adressen von Prozeduren/Funktionen gemeint welche ohne Klammer geschrieben werden müssen.

[Warf]

Hier sind Prozedur/Funktions-Variableninhalte und Adressen von Prozeduren/Funktionen gemeint welche ohne Klammer geschrieben werden müssen.

Da FPC typstreng ist, sowie das addressieren von Funktionsergebnissen nicht unterstützt werden all die Fehler aber zur Compilezeit entdeckt, was ein paar minuten mehrarbeit bedeutet, aber nicht zu irgendwelchen Signifikanten Fehlern führen kann.
bsp:

Code: Alles auswählen

function Foo: Integer; begin Result := 42; end;
 
var Bar: function: Integer;
  i: Integer;
begin
  Foo; // Kein fehler
  Bar := @Foo; // kein Fehler
  Bar := Foo; // Compilerfehler
  Bar; // Kein Fehler
  i := Bar; // Compilerfehler
 

Während es zwar 2 mögliche Kompilerfehler gibt, kann es keinen Semantischen Fehler geben. Daher ist es mMn. egal wie man es macht. Ich lass die Klammern am liebsten weg, da es einfach weniger tippaufwand ist. Problematisch kann es nur werden wenn man mit Funktionspointern arbeitet und die Ergebnisse Castet z.B. i := IntPtr(Bar); das sind aber Sonderfälle die zumindest bei mir so selten vorkommen, das ich grade nicht mal weiß ob ich solchen Code überhaupt je schonmal geschrieben habe

[marcov]

Aber eine Ausnahme gibt, bei rekursiven Funktionen.

Nur in $mode objfpc/fpc. In Delphi funktioniert das anders (mit @@)

Ältere Pascal Kompiler dürften eine Deklaration mit () nicht akzeptieren. (Ist eine Delphi oder spätere Turbo Pascal version erweiterung)

[Mathias]

Ältere Pascal Kompiler dürften eine Deklaration mit () nicht akzeptieren. (Ist eine Delphi oder spätere Turbo Pascal version erweiterung)

TP unmöglich, weil BP7 dies nicht übersetzt.

[Erwin]

Da schwirrt mir ja jetzt ganz schön der Kopf. Danke.
Und obendrein hat jeder auch noch für seine Schreibweise Argumente?!

Hier sind Prozedur/Funktions-Variableninhalte und Adressen von Prozeduren/Funktionen gemeint welche ohne Klammer geschrieben werden müssen.

Ist damit jetzt auch mein Beispiel gemeint? Oder gibt es Sonderfälle, wo man keine Klammern verwenden darf, wenn keine Daten übergeben werden. Anderseits klingt dies ja anderweitig logisch, das wenn keine Variablen vorhanden sind, dass man erst gar nicht den "Eindruck erwecken" sollte, es könnte was da sein. Anderseits könnte es ja sein, dass generelle nachgeschaut werden muss, und somit anderweitig das fehlen der Klammer es erschwert?

Da FPC typstreng ist, sowie das addressieren von Funktionsergebnissen nicht unterstützt werden all die Fehler aber zur Compilezeit entdeckt, was ein paar minuten mehrarbeit bedeutet, aber nicht zu irgendwelchen Signifikanten Fehlern führen kann.

Genau das ist es, was ich teils befürchte: Dass die eine oder andere Schreibweise doch verkehrt ist, aber in dem Fall der Compiler dies dann schon richtet, also dennoch richtig in Maschinensprache (?) "übersetzt". Was ich aber in dem Fall nicht unbedingt für eine gute Idee halte (falls der Compiler dies ausbügelt). Man ist ja doch eh gewöhnt, alles total richtig schreiben zu müssen? Und dennoch gibt es paar Ausnahmen, wo es scheinbar egal ist?

Ältere Pascal Kompiler dürften eine Deklaration mit () nicht akzeptieren. (Ist eine Delphi oder spätere Turbo Pascal version erweiterung)

War dies nur beim Aufruf so, oder auch bei der Erstellung?

TP unmöglich, weil BP7 dies nicht übersetzt.

TP? Turbo Pascal, vermute ich mal? BP7? Borland Pascal 7? Also Delphi 7? Kann das sein?
Und Du sagst wiederum, BP7 hätte es ohne Klammer nicht übersetzt? Verstehe ich das jetzt richtig?

Also so langsam glaube ich auch, dass es egal ist. Nicht weil ich davon überzeugt wäre, dass dem wirklich so ist. Aber langsam bin ich davon überzeugt, dass man nicht ohne weiteres wirklich feststellen kann, was richtig ist, und von daher ... bevor es gar nicht mehr weiter geht, ... .

[Mathias]

Und Du sagst wiederum, BP7 hätte es ohne Klammer nicht übersetzt? Verstehe ich das jetzt richtig?

Nein umgekehrt.

Code: Alles auswählen

WriteLn;    // geht
WriteLn();  // geht nicht

[Erwin]

Und Du sagst wiederum, BP7 hätte es ohne Klammer nicht übersetzt? Verstehe ich das jetzt richtig?

Nein umgekehrt.

Code: Alles auswählen

WriteLn;    // geht
WriteLn();  // geht nicht

Dieses Beispiel ist jetzt aber keine eigene Prozedure? Und müsste man da nicht sogar eine Variable zum Ausgeben übergeben? Das finde ich ja sehr verwirrend? Scheint da ja fast schon so zu sein, dass obwohl was übergeben werden muss, es dennoch darauf verzichten kann, vorausgesetzt dass auch auf die Klammern verzichtet wird. Für mich ist das somit eher ein Sonderfall. Also Ein entweder Alles: ('WriteLn(Text)') oder gar Nichts ('WriteLn'), es aber kein Halb-Halb erlaubt ('WriteLn()'). Was meiner Meinung nach in dem Fall auch Sinn macht. Weil wenn man schon dann Klammern macht, dann kann man bei dem Befehl auch davon ausgehen, dass man der Funktion/Prozedure was übergeben will, und dies der Schreiber eben vergessen hat?

Habe mal meine 5 Bücher zu Delphi überflogen. Nur in einem großen Wälzer zu Delphi 7 fand ich halbes Dutzend an Prozedure-Beispiele ohne Werteübergabe. Der Autor hat all diese komplett ohne Klammern geschrieben. Bei der Erstellung und Aufruf. Hm... . Also doch ohne Klammern?

Werde jetzt ohne Klammern schreiben. Zum einen wird dadurch der Code etwas kürzer, und zum anderen hoffe ich mal, dass der Compiler es ebenso handhabt, also überall an Code spart, und ich somit mit dem im Einklang bin?

Schade dass sich da überall totaler Wildwuchs durchsetzt hat. Bei der Gestaltung und Form, wäre es noch ok. Aber nicht wenn es um Befehle geht, finde ich.

[Thandor]

Also ich schreibe die Klammern immer mit, auch wenn ichg nichts übergebe, denn gerade bei größeren Projekten kann es sein, dass mann nach Jahren nicht mehr jede Funktion oder Procedure beim Namen kennt. Erst recht nicht, wenn diese aus fremden Units kommen. So ist dann immer deutlich zu erkennen, dass eine Procedure/Funktion aufgerufen wird.

Probleme hatte ich damit noch nie.

[Mathias]

So ist dann immer deutlich zu erkennen, dass eine Procedure/Funktion aufgerufen wird.

Stimmt da hast du recht, so weis man nicht, ob Test eine Variable oder eine Funktion ist.

Code: Alles auswählen

i := Test;

[m.fuchs]

Stimmt da hast du recht, so weis man nicht, ob Test eine Variable oder eine Funktion ist.

Code: Alles auswählen

i := Test;

Was nicht passiert, wenn man mal anfängt Bezeichner mit vernünftigen Namen zu versehen.

Code: Alles auswählen

CurrentData := GetTestData;

Code: Alles auswählen

CurrentData := TestData;

[Mathias]

Was nicht passiert, wenn man mal anfängt Bezeichner mit vernünftigen Namen zu versehen.

Da muss ich zustimmen, vielfach werden unlogische Namen für Funktionen verwendet. Ein Set und Get ist immer gut.
Zum Glück, gibt es sehr selten Funktionen, welche keine Übergabeparameter brauchen. Mir kommt momentan nicht mal einer Funktion ohne Parameter in Sinn, ausser bei eine Getter welcher in einer Class verwendet wird und da nimmt man sowieso eine property.

[Thandor]

Da hast du natürlich recht. Da bemühe ich mich auch immer sehr...

ABER bei fremden Units hat mann nicht immer Einfluss auf die Namensgebung und alleine schon desshalb habe ich mir angewöhnt einheitlich die Klammern immer mit zu setzen beim Aufruf.

[indianer-frank]

Mir kommt momentan nicht mal einer Funktion ohne Parameter in Sinn...

Na ja, Pi und Random sind werden doch häufig gebraucht. Und Pi() wäre doch äußerst ungewöhnlich! Ich denke, viele wissen noch nicht einmal, daß das eine Funktion ist.