Anordnung Subroutines

[Pensky]

Hallo,
gibt es Empfehlungen oder sogar zwingende Gründe, Subroutinen im Perl-Programm vor oder hinter den "main"-Teil (bzw. vor oder hinter die rufende Stelle) zu platzieren?
Danke
Pensky

[Beat]

gibt es Empfehlungen oder sogar zwingende Gründe, Subroutinen im Perl-Programm vor oder hinter den "main"-Teil (bzw. vor oder hinter die rufende Stelle) zu platzieren?

Anonyme Subroutinen:
Sie gehören in den Kontext, welcher ihren Return unmittelbar verwendet.

Benannten Subfunktionen
Frage sollte lauten:
Gehören sie vor oder nach einer exit; Anweisung?

Scheissegal, solange sie im main package stehen.
Ich bevorzuge jedoch die folgende Abfolge:

--Initialisierung
--kurzes Hauptprogramm das bestimmt mit einem exit; endet
--Die Sammlung der Subfunktionen,
  nach bestimmten Richtlinien verfasst und thematisch sortiert.

Auf jeden Fall aber müsssen sie vor einem
__END__ Token stehen, sofern du willst, dass sie ausführbar sind.
Sie müssen auch vor einem __DATA__ Token stehen, es sei denn, du betrachtest eine Sub als DATA im Sinne von Filedata.

mfg Beat;

[Pensky]

Hallo,

--Initialisierung
--kurzes Hauptprogramm das bestimmt mit einem exit; endet
--Die Sammlung der Subfunktionen,
  nach bestimmten Richtlinien verfasst und thematisch sortiert.

Bis hierher ist es verstanden.

Auf jeden Fall aber müsssen sie vor einem
__END__ Token stehen, sofern du willst, dass sie ausführbar sind.
Sie müssen auch vor einem __DATA__ Token stehen, es sei denn, du betrachtest eine Sub als DATA im Sinne von Filedata.

Den Rest leider nicht, aber da ich diese Feinheiten nicht kenne und damit nicht verwende, ist es im Augenblick auch nicht so wichtig.
Danke
Pensky

[Freddy]

http://de.selfhtml.org/perl/sprache/tokens.htm

"Hinter den Tokens __END__ und __DATA__ kann z.B. Text notiert werden, der aber nicht mehr als Quellcode des Scripts interpretiert wird."

[N.]

Eindeutig nach alter Pascal-Konvention gehören Subs vor den Hauptteil.

Geht:

  
    use strict;  
    sub foo {  
        say 'hello';  
    }  
    foo;  

Geht nicht:

  
    use strict;  
    foo;  
    sub foo {  
        say 'hello';  
    }  
  
    Bareword "foo" not allowed while "strict subs" in use at [...]  
    Execution [...] aborted due to compilation errors.  

PS: Wer parameterlose Subs mit runden Klammern aufruft, ist ein Javaweichspüler.

[Beat]

Eindeutig nach alter Pascal-Konvention gehören Subs vor den Hauptteil.

NEIN!

  
#!C:/Programme/Perl/bin/perl.exe -w  
#  
use strict;  
  
  
BEGIN {  
 use CGI::Carp qw(carpout);  
 open(LOG, ">>error.txt")  or  die "Unable to append to error.txt: $!\n";  
 carpout(*LOG);  
}  
  
&my_func;   # Old Style  
my_func();  # Good Style  
sub my_func{  
  print "hallo\n";  
}  
my_func;    # CIA/Mossad Style  
  
  
sleep(10);  
  
exit;  
__END__  

PS: Wer parameterlose Subs mit runden Klammern aufruft, ist ein Javaweichspüler.

Behalte deine Polemik für dich. Wer will schon deinen Chaoscode.

mfg Beat;

[N.]

Das war keine Polemik. Das war Humor, Edward. Du darfst ruhig lachen.

Ehrlich gesagt, finde ich dein Gegenbeispiel viel chaotischer. Das würde bei uns im Codereview gnadenlos zurückgewiesen werden. Typeglobs statt lexikalische Handles? Zwei- statt Drei-Argumente-Form von open? "Old" statt "Cargokult" (&sub macht in Perl5 nicht das, was du denkst, dass es tut)?

Mein Beispiel war hingegen minimal, um das Problem aufzuzeigen. Ich bin mit diesem Gotcha bezüglich "Bareword ... not allowed" vertraut, aber das kann man nicht über alle Mitprogrammierer sagen. Aus diesem Grund haben wir die Richtlinie eingeführt, konsequent der Konvention zu folgen, den Hauptteil am Ende zu haben. So tritt dieses Problem nie aus, es *kann* nicht auftreten.

Es hört ja bei Subs nicht auf. Definieren wir uns mal eine Konstante, die mehrmals benötigt wird, bspw.:

  
        Readonly our $ITEM_MARGINS => 4;  

Hier hilft keine alternative Aufrufssyntax; dies *muss* schlichtweg vor dem Hauptteil stehen. Ebenso müssen Pragmas und Module auch zusammen am Anfang stehen; dadurch importierte Symbole sind erst hinter der use-Anweisung (trotz Compile-Laufzeit!) verfügbar.

Es ist also einfach gute und notwendige Praxis, dass der Hauptteil erst zum Schluss kommt. Das ist in C so und und in Pascal und gilt vermutlich auch für den Rest der Algol-Nachkömmlinge.

[Beat]

Das war keine Polemik. Das war Humor, Edward. Du darfst ruhig lachen.
Ehrlich gesagt, finde ich dein Gegenbeispiel viel chaotischer.

Es ist nicht ein Gegenbeispiel, es behandelt drei valide Arten, wie eine Funktion ohne Parameter aufgerufen werden kann. Deinen Vorschlag musste ich ans Ende stellen, damit er valide ist.

Das würde bei uns im Codereview gnadenlos zurückgewiesen werden.

Was? Und wer ist euer Codereview?

Typeglobs statt lexikalische Handles?

Bleib beim Thema. Wir sind bei Subfunktionen.
Deine Sophistereien kannst du dir sparen.

Zwei- statt Drei-Argumente-Form von open? "Old" statt "Cargokult" (&sub macht in Perl5 nicht das, was du denkst, dass es tut)?

Sorry, ich weiss nicht aus welcher Glaskugel du ziehst, was ich denke, was &func im Gegensatz zu func() machen solle oder nicht.

Geh woanders spielen.
Hier ging's um Perl, nicht nicht um eure Codereview Richtlinien für nicht spezifizierte Scriptsprachen.

mfg Beat;

[steckl]

Hi,

Es ist also einfach gute und notwendige Praxis, dass der Hauptteil erst zum Schluss kommt. Das ist in C so und und in Pascal und gilt vermutlich auch für den Rest der Algol-Nachkömmlinge.

In C gibt es für sowas Funktionsprototypen.
Ich finde es viel übersichtlicher wenn vor main() nur die Prototypen der Funktionen stehen und die eigentliche Implementierung dann erst nach main() erfolgt.

mfG,
steckl

[Alexander (HH)]

Moin Moin!

In C gibt es für sowas Funktionsprototypen.

Das geht auch in Perl:

sub foo($$);

...

sub foo($$)
{
    # ...
}

oder wahlweise auch

sub foo;

...

sub foo
{
    # ...
}

Ich finde es viel übersichtlicher wenn vor main() nur die Prototypen der Funktionen stehen und die eigentliche Implementierung dann erst nach main() erfolgt.

Ich halte das in aller Regel für überflüssige Tipperei und bevorzuge ganz klar die Pascal-Reihenfolge: package, use, our, sub, Initialisierung. Auch wenn Perl darauf nicht besteht.

There is more than one way to do it.

Alexander

[Patrick Andrieu]

Hallo N.!

Eindeutig nach alter Pascal-Konvention gehören Subs vor den Hauptteil.

Wo für Perl wird es vorgeschrieben/empfohlen/vermerkt?

PS: Wer parameterlose Subs mit runden Klammern aufruft, ist ein Javaweichspüler.

Wo wird es geschrieben/erwähnt/vermerkt?

Viele Grüße aus Frankfurt/Main,
Patrick

[Siechfred]

Geht:
[...]
Geht nicht:

Was Du damit beweisen willst, verstehe ich nicht.

Bareword "foo" not allowed while "strict subs" in use at [...]

Das kommt davon, wenn man parameterlose subs ohne Klammern aufruft.

PS: Wer parameterlose Subs mit runden Klammern aufruft, ist ein Javaweichspüler.

Wer parameterlose Subs ohne runde Klammern aufruft und solche Begründungen liefert, hat perlsub entweder nicht gelesen oder nicht verstanden. Oder anders: Wer mit der Bibel wedelt, muss sich nicht wundern wenn der Compiler "Bareword 'buddha' not allowed while bible in use" meckert ;)

Siechfred

[N.]

Lieber Siechfried, liest du auch den Rest des Threads, bevor du antwortest?

*Ich* weiß, dass es diesen Fehler ohne Klammern gibt. Was meinst du, wieso ich sonst das Postskriptum so schreiben könnte? Kann man meinen Wissensstand nicht daraus ableiten, oder übersiehst du das absichtlich?

In einer idealen Welt kann jeder die ganze Perl-Doku auswendig und macht nie Fehler beim programmieren. Ist natürlich bei weitem nicht so.

Es geht darum, diesen Programmierfehler in der Zusammenarbeit mit mehreren Leuten einfach zu eliminieren. Wenn man den Hauptteil an den Schluss stellt, kann er schlicht nicht mehr auftreten. Diese Lösung ist wesentlich besser, als die Richtlinie aufzustellen, dass alle Aufrufe Klammern haben müssen.

Gründe dafür habe ich schon in der anderen Nachricht genannt. Mir fallen noch zwei andere ein, aber vielleicht überlegst du mal selber.

[Siechfred]

*Ich* weiß, dass es diesen Fehler ohne Klammern gibt. Was meinst du, wieso ich sonst das Postskriptum so schreiben könnte? Kann man meinen Wissensstand nicht daraus ableiten, oder übersiehst du das absichtlich?

Sorry, aber ich kann aus "Javaweicheier" nichts Substanzielles ableiten.

Es geht darum, diesen Programmierfehler in der Zusammenarbeit mit mehreren Leuten einfach zu eliminieren.

Warum? Perl lässt (absichtlich?) offen, ob man parameterlose Subs mit oder ohne Klammern aufruft. Lässt man sie weg, muss man die Sub halt vorher deklariert haben, ich sehe aber nicht, dass das irgendeinen Mehrwert bringt.

Wenn man den Hauptteil an den Schluss stellt, kann er schlicht nicht mehr auftreten.

Eine nicht deklarierte Sub geht auch in die Hose, wenn man sie mit Klammern aufruft. Insofern sehe ich nachwievor keinen Nutzen. Bei der prozeduralen Programmierung hat jeder seine Vorliebe, meine ist "Hauptteil" und darauf folgende die Deklaration der Subs. Man muss sich nur der Auswirkungen bewusst sein.

Diese Lösung ist wesentlich besser, als die Richtlinie aufzustellen, dass alle Aufrufe Klammern haben müssen.

Sie ist genauso gut oder schlecht. Mag sein, dass sie für die in Deinem Fall Verantwortlichen als der Königsweg für einen einheitlichen Programmierstil angesehen wird, und ich will auch gar nicht abstreiten, dass dieser Ansatz was für sich hat (konsequenter lexical scope), nur daraus abzuleiten, dass es in Perl irgendwelche Konventionen zur Ausgangsfrage gäbe, ist schlichtweg falsch.

Siechfred