aus dem Kamelbuch

Hallo,

ich versuche folgedes aus dem Programmieren mit perl:

while ( <> ) {

next unless s/^(.*?):\s*//;
$HoL{$1} =3D [ split ];

}

die Hash Datei sieht folgenden aus

1: 1 2 3 4 5 6
2: 34 5 7 8 9
usw.

wenn ich der Skript auf eine Win Xp Pro mit perl activestate 5.8

perl -w HoL.pl Hash.txt

aufrufe

Bekomme ich folgende Fehlermeldung:

Name "main::HoL" used only once: possible typo at HoL.pl line 12

genau das gleiche wenn das skript so umgeschrieben wird:

while ($line =3D <>){
($who, $rest) =3D split /:\s*/, $line, 2;
@field =3D split ' ', $rest;
$HoL{$who} =3D [ @field ];

}

was mache ich falsch?

Grüße.

Xaver

Re: aus dem Kamelbuch

javier@callwayonline.de wrote:

> Bekomme ich folgende Fehlermeldung:
>
> Name "main::HoL" used only once: possible typo at HoL.pl line 12

Das ist keine Fehlermeldung, sondern eine Warnung.

> was mache ich falsch?

Stimmt es denn nicht, was die Warnung sagt? Perl bemerkt halt, daß
Dein Programm recht sinnlos ist und kann sich einen Kommentar dazu
nicht verkneifen.

Aber im Ernst. Es fehlt folgendes am Anfang Deines Skriptes:

use strict;
use warnings;

our %HoL; # our hash of lines

Re: aus dem Kamelbuch

Ingo Menger schrieb:

> use strict;
> use warnings;
>
> our %HoL; # our hash of lines
>
Vielleicht sollte man einfach auch mal was damit machen, so wie z.B.
ausgeben oder so..

use Data::Dumper;

print Data::Dumper->Dump([\%HoL],[qw/%HoL/]);

--
$_='';s%%`^.*`s;.*;uhtnmo;;a>lha~a>inu~a>fmk~a>rou~a>duM~a>b tl~s;&&&&&&;
!d1!l2!b3!i4!f5!r6q(?);e;Z``}a>&&&`sub# "1#{#"_=shift#;s^"2^"3#^;``;~`
return #"_#}``^!&&`"1(#""2)#\.`Z%x;s~Z~print~g;s/#/\\/g;
s/`(.)(.+?)`(.+?)`/s$1$2$1$3$1g\;/gsx;s;&;(.);g;y^"^$^;print ;

Re: aus dem Kamelbuch

On Thu, 27 Jul 2006 02:23:28 -0700, Ingo Menger wrote:
> Aber im Ernst. Es fehlt folgendes am Anfang Deines Skriptes:
>
> use strict;
> use warnings;
>
> our %HoL; # our hash of lines

Warum our und nicht my?

hp

--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: aus dem Kamelbuch

Xaver:

> ich versuche folgedes aus dem Programmieren mit perl:
>
> while ( <> ) {
>
> next unless s/^(.*?):\s*//;
> $HoL{$1} = [ split ];
>
> }

[...]

> Bekomme ich folgende Fehlermeldung:
>
> Name "main::HoL" used only once: possible typo at HoL.pl line 12
>
> [...]
>
> was mache ich falsch?

Falsch gar nichts, aber du weist Hashelementen Werte zu, verwendest die
Elemente bzw. den Hash in deinem Programm aber nicht weiter. Ein Grund
dafür _könnte_ laut Perl sein, dass du dich vertippt hast und den Hash
woanders in deinem Skript zB. als "%HOL" (dh., mit großen "O") ansprichst.
Diese Meldung - es ist übrigens nur eine Warnung, kein Fehler - weist dich
auf diese Möglichkeit hin.

Hier trifft es allerdings nicht zu, da du den Hash ja tatsächlich nur
einmal -
in der Schleife - durch Zuweisung an Elemente ansprichst. Die Meldung
läßt sich unterdrücken, wenn du - wie neuerdings scheinbar modern -
den Hash deklarierst, dh. am Skriptbeginn

my %HoL;

schreibst. Wenn du - wie ebenfalls neuerdings überall vorgeschlagen -
"use strict" verwendest, musst du das sogar tun, sonst beschwert sich
der Compiler mit

Global symbol "%HoL" requires explicit package name at ...

PS: Ich habe Perl C letztlich auch deswegen vorgezogen, weil es mir
genau das - das Deklarieren von Variablen - erspart, aber scheinbar
ist diese Eigenschaft heutzutage nicht mehr gefragt. Schade - jeder, der
schon einmal zeilenweise Deklarationen von Variablen und Strukturen
in einem C Programm erlebt hat, wird mich verstehen!

LG, Ferry

--
Ing. Ferry Bolhar
Municipality of Vienna, Department 14
A-1010 Vienna / AUSTRIA
E-mail: bol@adv.magwien.gv.at

Re: aus dem Kamelbuch

Am Thu, 24 Aug 2006 08:22:37 +0200 schrieb Ferry Bolhar:

>
> PS: Ich habe Perl C letztlich auch deswegen vorgezogen, weil es mir
> genau das - das Deklarieren von Variablen - erspart, aber scheinbar
> ist diese Eigenschaft heutzutage nicht mehr gefragt. Schade - jeder, der
> schon einmal zeilenweise Deklarationen von Variablen und Strukturen
> in einem C Programm erlebt hat, wird mich verstehen!
>

Du darfst die Variablen auch nicht _am Skriptbeginn_ deklarieren, wie
du es oben (im von mir geschnippten Teil) geschrieben hast. Und gerade
Perl erlaubt es, die Deklaration bis zum letzten Punkt herauszuzögern.

Joachim

Re: aus dem Kamelbuch

On 2006-08-24 06:22, Ferry Bolhar wrote:
> Die Meldung läßt sich unterdrücken, wenn du - wie neuerdings scheinbar
> modern - den Hash deklarierst,

Vollkommen richtig formuliert. Das ist nur scheinbar modern. In
Wirklichkeit ist das seit langem "best practice".

> dh. am Skriptbeginn
>
> my %HoL;
>
> schreibst.

Nein, das ist keine so gute Idee. Variablen sollten immer im
kleinstmöglichen Bereich sichtbar sein. Meistens gehört das my also in
einen inneren Block, nur selten auf die oberste Ebene, und selbst dann
nicht unbedingt an den Scriptbeginn, sondern eher in die Nähe der
Funktionen, die die Variable tatsächlich verwenden.


> PS: Ich habe Perl C letztlich auch deswegen vorgezogen, weil es mir
> genau das - das Deklarieren von Variablen - erspart,

Da fallen mir irgendwie wesentlich lästigere Dinge ein, die mir Perl
erspart, vor allem das Low-Level-Memory-Management.

> aber scheinbar ist diese Eigenschaft heutzutage nicht mehr gefragt.

War die in den letzten 40 Jahren jemals gefragt? Außer in
Wegwerf-Scripts natürlich. Undeklarierte Variablen sind
notwendigerweise global, weil der Compiler den beabsichtigten Scope
nicht erraten kann, und globale Variablen will man eigentlich möglichst
minimieren. Mir reicht schon, dass ich immer wieder mal vergesse $_ zu
lokalisieren, wo es notwendig wäre.


> Schade - jeder, der schon einmal zeilenweise Deklarationen von
> Variablen und Strukturen in einem C Programm erlebt hat, wird mich
> verstehen!

Nein, ich verstehe es nicht. Etwas lästig war in C vor C99, dass man
Variablen am Anfang des Blocks deklarieren musste, das führte
gelegentlich dazu, dass Variablen etwas unangenehm weit weg von ihrer
Verwendung deklariert waren. An der Tatsache, dass man deklarieren muss,
hatte ich aber nie was auszusetzen. Vielleicht nur, weil ich in C nicht
sehe, wie es anders gehen soll: Welchen Typ soll eine undeklarierte
Variable haben? int?

In Perl gibt es ja nicht wirklich Deklarationen: my und local legen nur
den Scope fest.

hp


--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: aus dem Kamelbuch

Joachim Pense:

> Du darfst die Variablen auch nicht _am Skriptbeginn_ deklarieren, wie
> du es oben (im von mir geschnippten Teil) geschrieben hast. Und gerade
> Perl erlaubt es, die Deklaration bis zum letzten Punkt herauszuzögern.

Was verstehst du unter "letzter Punkt"?

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: aus dem Kamelbuch

Peter J. Holzer:

> Vollkommen richtig formuliert. Das ist nur scheinbar modern. In
> Wirklichkeit ist das seit langem "best practice".

Naja, vielleicht für jemanden, der von Anfang an die Option hatte, Sprachen
zu verwenden, die die Variablendeklaration erlauben.

Ich kommt aus der VMS-Welt, und der dortige Command Line Interpreter
(DCL) kennt - sowie die meisten UNIX-Shells - keinerlei Möglichkeiten,
Variablen zu deklarieren. Eine Variable gilt als deklariert, sobald sie zum
erstenmal verwendet wird. Punkt.

Als ich zum erstenmal mit Perl zu tun hatte (das war noch Perl 4, wo es
"our" und "my" ja noch nicht gab), habe ich das Verwenden von Variablen
ohne vorherige Deklaration eins zu eins übernommen und hätte es als
ziemlich störend und behindernd empfunden, wenn das auf einmal notwendig
gewesen wäre. Wahrscheinlich hätte ich dann auf die Benutzung von Perl
verzichtet und stattdessen mit der Shell und/oder awk/sed etc. gearbeitet.

Die vorherige Deklaration von Variablen befreit einen Programmier nämlich
nicht davon, sich zu überlegen, was er tut. Und nur genau das sollte "Best
Practice" sein. Der Weg dorthin sollte offen sein und niemandem Praktiken
abverlangen, mit denen er nicht glücklich wird.

> Nein, das ist keine so gute Idee. Variablen sollten immer im
> kleinstmöglichen Bereich sichtbar sein. Meistens gehört das my also in
> einen inneren Block, nur selten auf die oberste Ebene, und selbst dann
> nicht unbedingt an den Scriptbeginn, sondern eher in die Nähe der
> Funktionen, die die Variable tatsächlich verwenden.

Natürlich.Das "Am Skriptbeginn" war auf das Beispiel des OP bezogen.

> > PS: Ich habe Perl C letztlich auch deswegen vorgezogen, weil es mir
> > genau das - das Deklarieren von Variablen - erspart,
>
> Da fallen mir irgendwie wesentlich lästigere Dinge ein, die mir Perl
> erspart, vor allem das Low-Level-Memory-Management.
>
> > aber scheinbar ist diese Eigenschaft heutzutage nicht mehr gefragt.
>
> War die in den letzten 40 Jahren jemals gefragt?

Wie gesagt - das Deklarieren von Variablen (bei gleichzeitigem Fest-
legen des Types) habe ich immer als Einschränkung empfunden. Aber
wahrscheinlich sieht das jemand, der es nicht anders kennt, nicht so
eng.

> Außer in Wegwerf-Scripts natürlich.

Naja, das ist wohl eine philosophische Frage. Die von dir erwähnten
"Wegwerf-Skripts" sind oft schnell benötigte Lösungen, und wenn sie
so funktionieren, wie erwartet, was ist dann daran auszusetzen? Letztlich
geht es doch bei jedem Programm oder Skript darum, dass es das tut,
was der Programmierer will bzw. was von ihm verlangt wird.

> Welchen Typ soll eine undeklarierte Variable haben? int?

Den, den ich ihr zuweise. Und idealerweise später, wenn sie verwendet
wird, den, den der jeweilige Context benötigt. Wenn ich in Perl sage

$x = 5;
$y = $x + 10;
$z = $x . '10';

erhalte ich für $y den Wert 10, für $z den Wert '510'. Perl verwendet
also dieselbe Variable zweimal in unterschiedlichen Contexten, und das
ist genau das, was ich mir von einer "guten" Programmiersprache erwarten
würde. Und nicht, dass ich mich bei der Deklaration einer Variable
auf einen Typ festlegen muss, der es mir unmöglich macht, die Variable
ohne Hilfskonstrukte in anderen Contexten zu verwenden.

> In Perl gibt es ja nicht wirklich Deklarationen: my und local legen nur
> den Scope fest.

In Perl6 wird es "wirkliche" Deklarationen geben - wobei ich hoffe, dass
auch das nur eine Möglichkeit bleibt, die man verwenden kann oder auch
nicht. Sollte dem nicht so sein, so wird für mich der Umstieg auf Perl 6
solange wie nur möglich kein Thema sein.

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: aus dem Kamelbuch

Ferry Bolhar wrote:
> Die von dir erwähnten "-Skripts" sind oft schnell benötigte
> Lösungen, und wenn sie so funktionieren, wie erwartet, was ist dann
> daran auszusetzen?

Nichts, ganz im Gegenteil.

> Letztlich geht es doch bei jedem Programm oder Skript darum, dass es
> das tut, was der Programmierer will bzw. was von ihm verlangt wird.

Das ist aber nicht alles. Wenn es sich eben nicht um *Wegwerf*-Skripte
handelt, sollten sie z.B. auch wartbar sein.

lg,
daniel

Re: aus dem Kamelbuch

On 2006-08-25 13:33, Ferry Bolhar wrote:
> Peter J. Holzer:
>> Vollkommen richtig formuliert. Das ist nur scheinbar modern. In
>> Wirklichkeit ist das seit langem "best practice".
>
> Naja, vielleicht für jemanden, der von Anfang an die Option hatte, Sprachen
> zu verwenden, die die Variablendeklaration erlauben.
>
> Ich kommt aus der VMS-Welt, und der dortige Command Line Interpreter
> (DCL) kennt - sowie die meisten UNIX-Shells - keinerlei Möglichkeiten,
> Variablen zu deklarieren. Eine Variable gilt als deklariert, sobald sie zum
> erstenmal verwendet wird. Punkt.

Ich komme da eher aus der "Compilersprachen"-Welt. Zwar habe ich (wie
viele andere, die in den 80ern Programmieren gelernt haben,
wahrscheinlich auch) mit BASIC angefangen, das auch keine
Variablendeklarationen kannte, bin aber relativ bald zu Pascal und dann
C übergewechselt. Das sind aber statisch typisierte Sprachen und damit
ist eine Deklaration unerlässlich, weil der Typ einer Variablen eben zur
Compilezeit feststehen muss und es (zumindest in C) zu viele Typen gibt,
um das über Sigils oder Anfangsbuchstaben ("GOD is REAL", wie alte
Fortran-Programmierer wissen) festzulegen.

Shell-Scripts (und Awk-Scripts, etc.) habe ich natürlich auch viele
geschrieben, aber die waren immer eher klein. Für "richtige Programme"
habe ich C verwendet, weil die Shell für meinen Geschmack zuwenig
Möglichkeiten der Strukturierung bot, und weil einige C-Compiler (z.B.
der gcc) damals schon durchaus brauchbare Warnungen und Fehlermeldungen
ausspuckten. (Modula war mir zu umständlich, außerdem gab es keine
Modula-Compiler auf den Unix-Kisten, auf denen ich einen Account hatte)


> Als ich zum erstenmal mit Perl zu tun hatte (das war noch Perl 4, wo es
> "our" und "my" ja noch nicht gab), habe ich das Verwenden von Variablen
> ohne vorherige Deklaration eins zu eins übernommen

Ich auch, und ich mochte Perl nicht. Ich hatte ein paar Perl-Scripts von
meinem Vorgänger geerbt, die ich maintainen musste, und das war weniger
Arbeit als sie in C neu zu schreiben (außerdem war es damals gerade in,
CGI-Programme in Perl zu schreiben). Mit der Zeit habe ich dann
entdeckt, dass perl5 eigentlich eh fast alles hat, was man so braucht,
und habe mich mit dem Monstrum angefreundet.


> und hätte es als ziemlich störend und behindernd empfunden, wenn das
> auf einmal notwendig gewesen wäre. Wahrscheinlich hätte ich dann auf
> die Benutzung von Perl verzichtet und stattdessen mit der Shell
> und/oder awk/sed etc. gearbeitet.

Ich kannte Perl an sich seit ca. 1990, habe aber bis perl5 (1995) keinen
Grund gesehen, es zu verwenden - Perl-Scripts schienen mir um keinen
Deut wartbarer zu sein als Shell/Awk-Scripts, und portabler waren sie
damals auch nicht (perl musste man fast überall erst installieren).

> Die vorherige Deklaration von Variablen befreit einen Programmier nämlich
> nicht davon, sich zu überlegen, was er tut.

Das soll es auch nicht. Die Deklaration dient dazu, dass der
Programmierer dem Compiler mitteilen kann, was er sich überlegt hat.
(In Perl ist das zugegenermaßen wenig. Mehr als "diese Variable brauche
ich von hier bis hier" kann man ohne Zusatzmodule nicht ausdrücken)

> Und nur genau das sollte "Best Practice" sein. Der Weg dorthin sollte
> offen sein und niemandem Praktiken abverlangen, mit denen er nicht
> glücklich wird.

TMTOWTDI. Perl verlangt von Dir nicht, dass Variablen deklarierst. Unter
Umständen verlangen es Deine Team-Kollegen.

>> > PS: Ich habe Perl C letztlich auch deswegen vorgezogen, weil es mir
>> > genau das - das Deklarieren von Variablen - erspart,
[...]
>> > aber scheinbar ist diese Eigenschaft heutzutage nicht mehr gefragt.
>>
>> War die in den letzten 40 Jahren jemals gefragt?
>
> Wie gesagt - das Deklarieren von Variablen (bei gleichzeitigem Fest-
> legen des Types) habe ich immer als Einschränkung empfunden. Aber
> wahrscheinlich sieht das jemand, der es nicht anders kennt, nicht so
> eng.

Ich kenne es auch anders. Ich habe mit BASIC angefangen und etliche
Shell-Scripte verbrochen. Aber ich habe die Möglichkeit, Variablen zu
deklarieren nie als Einschränkung gesehen, sondern im Gegenteil als
Arbeitserleichterung. Vielleicht bin ich auch nur von BASIC
traumatisiert.


>> Außer in Wegwerf-Scripts natürlich.
>
> Naja, das ist wohl eine philosophische Frage. Die von dir erwähnten
> "Wegwerf-Skripts" sind oft schnell benötigte Lösungen, und wenn sie
> so funktionieren, wie erwartet, was ist dann daran auszusetzen?

Mangelnde Wartbarkeit. Die ist bei Wegwerf-Scripts per definitionem kein
Problem (weil die eben nach Gebrauch weggeworfen werden und nicht
gewartet werden müssen) aber bei Nicht-Wegwerf-Scripts eben schon. Da
kommt es natürlich auch wieder auf die Länge an: In einem 5-Zeiler sind
globale Variablen kein Problem, bei 100 Zeilen noch kein großes. Wenn
man aber mal in die Größenordnung von ein paar 1000 Zeilen kommt, dann
wird es schon mühsam, alle Variablen im Kopf zu behalten und keine
versehentlich doppelt zu verwenden.

>> Welchen Typ soll eine undeklarierte Variable haben? int?
>
> Den, den ich ihr zuweise.

Du hast hier den Kontext weggeworfen. In diesem Absatz ging es explizit
um C. Und C ist - im Gegensatz zu Perl - eine statisch typisierte
Sprache. Der Typ jeder Variable (und jedes Ausdrucks) steht zur
Compilezeit fest. Eine Analyse, welchen Typ du zuweist, wäre theoretisch
ohne explizite Deklarationen in C möglich, wenn der gesamte Source-Code
vorliegt, aber sehr aufwendig. Das hätte sicher die Möglichkeiten einer
PDP-11 anno 74 überschritten :-).

hp


--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: aus dem Kamelbuch

On 2006-08-25 13:06, Ferry Bolhar wrote:
> Joachim Pense:
>
>> Du darfst die Variablen auch nicht _am Skriptbeginn_ deklarieren, wie
>> du es oben (im von mir geschnippten Teil) geschrieben hast. Und gerade
>> Perl erlaubt es, die Deklaration bis zum letzten Punkt herauszuzögern.
>
> Was verstehst du unter "letzter Punkt"?

Den Punkt, an dem die Variable erstmals verwendet wird, bzw. an dem sie
existieren muss, um ihren Zweck erfüllen zu können.

Also z.B.


sub bla {
my ($arg1, $arg2) = @_;

... viel Code ...

my $x = blub();

my %h;

for ($x->members()) {
... noch mehr code ...

my $y = $_->value;
print $y;
if (++$h{$y} > THRESH) {
blow_whistle($x, $y);
}
}
}

Hier werden $x und $y erst bei der ersten Verwendung deklariert, sie
existieren nur von dort bis zum Ende des Blocks, in dem sie tatsächlich
verwendet werden. %h wird zwar auch nur innerhalb der Schleife
verwendet, muss seinen Wert aber von einem Schleifendurchlauf zum
nächsten behalten und wird daher unmittelbar vor der Schleife
deklariert. So hat jede Variable den geringstmöglichen Scope und man
weiß beim Lesen des Codes, in welchem Bereich eine Änderung der Variable
direkte Auswirkungen hat.

In C (vor C99) hingegen mussten Variablen am Anfang des Blocks
deklariert werden. Hätte Perl diese Einschränkung, sähe der Code so aus:


sub bla {
my ($arg1, $arg2) = @_;
my ($x, %h);

... viel Code ...

$x = blub();

for ($x->members()) {
my $y;

... noch mehr code ...

$y = $_->value;
print $y;
if (++$h{$y} > THRESH) {
blow_whistle($x, $y);
}
}
}

Obwohl diese Variablen also in "... viel Code ..." und "... noch mehr
code ..." nicht verwendet werden, existieren sie dort und man muss sich
den Code erst durchlesen, um sicher zu gehen, dass sie dort nicht
verwendet werden.

Noch schlimmer ist es in Pascal, wo Variablen überhaupt nur am Anfang
einer Funktion definiert werden können. Hier würde dannn auch die
Deklaration von $y aus der Schleife herauswandern und man müsste sich
die ganze Funktion durchlesen um zu sehen, ob die Variable, die
tatsächlich nur in 3 aufeinanderfolgenden Zeilen verwendet wird, nicht
sonst auch noch irgendwo einen Effekt hat. (Da in Pascal außerdem
Funktionen verschachtelt werden können und das auch üblich ist, ist die
Deklaration of mehrere Seiten von der Verwendung entfernt.

Am schlimmsten ist natürlich eine Sprache ohne Deklaration: Da sind alle
Variablen global und man muss immer das gesamte Script betrachten.

hp

--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: aus dem Kamelbuch

Daniel Tiefnig:

>> Letztlich geht es doch bei jedem Programm oder Skript darum, dass es
>> das tut, was der Programmierer will bzw. was von ihm verlangt wird.
>
> Das ist aber nicht alles. Wenn es sich eben nicht um *Wegwerf*-Skripte
> handelt, sollten sie z.B. auch wartbar sein.

Richtig. Aber wer definiert "wartbar"?

Wie schon erwähnt, komme ich aus einem Bereich, wo es in Skriptsprachen
nicht möglich war (und ist), Variable zu deklarieren. Und daher hätten auch
meine Kollegen, die es ebenfalls nicht anders kennen, keine Probleme, meine
Skripts "zu warten" (und umgekehrt). Wir tun uns eher schwer, Programme
zu warten, in denen erst ellenlang Variable deklariert werden, bevor man auf
die erste echte Anweisung stößt. Wir haben PL/I-Progamme, da ist das
Verhältnis Deklararionen:Code etwa 50:50. Und _DAS_ würde ich als
schwer wartbar bezeichnen.

Aber wie schon erwähnt: alles Geschmackssache. Es ist auch OK, wenn
jemand in Perl jede Variable vor der Benutzung mit "my" bzw. "our"
deklariert,
wenn er meint, dadurch besser Code zu schreiben. Ich wollte nur aufzeigen,
dass das nicht notwendigerweise immer der Fall sein muss und dass man auch
mit "use strict", "use warnings", "my" und "our" nicht davon befreit ist,
sich zu
überlegen, was man macht und nach dem Programmieren seinen Code hin-
reichend auszutesten. Und dass (zumindest) ich deswegen Deklarationen
nicht automatisch als "Best Practice" bezeichnen würde.

LG, Ferry
--

Re: aus dem Kamelbuch

Peter J. Holzer:

>. Zwar habe ich (wie
> viele andere, die in den 80ern Programmieren gelernt haben,
> wahrscheinlich auch) mit BASIC angefangen, das auch keine
> Variablendeklarationen kannte,

Aber - zumindest die BASICs, die ich kannte - hatten implizite Typen-
festlegungen in den Namen: X = float, X$ = string und X% = integer, IIRC.
Also führte zB. ein X = "HALLO" zu einem "Type mismatch", es musste
X$ = "HALLO" heißen. Und ein ähnliches Schema gab es, wie du ja weiter
unten schreibst, auch in Fortran.

> bin aber relativ bald zu Pascal und dann
> C übergewechselt. Das sind aber statisch typisierte Sprachen und damit
> ist eine Deklaration unerlässlich, weil der Typ einer Variablen eben zur
> Compilezeit feststehen muss und es (zumindest in C) zu viele Typen gibt,
> um das über Sigils oder Anfangsbuchstaben ("GOD is REAL", wie alte
> Fortran-Programmierer wissen) festzulegen.

Ja, dass es Deklarationen in Compilersprachen geben muss, ist klar (es muss
sie ja auch in Assembler geben), aber in Skriptsprachen? Das war ja eben für
mich immer einer der Vorzüge einer Skriptsprache, das man auf Deklarationen
verzichten kann.

>> Die vorherige Deklaration von Variablen befreit einen Programmier nämlich
>> nicht davon, sich zu überlegen, was er tut.
>
> Das soll es auch nicht. Die Deklaration dient dazu, dass der
> Programmierer dem Compiler mitteilen kann, was er sich überlegt hat.
> (In Perl ist das zugegenermaßen wenig. Mehr als "diese Variable brauche
> ich von hier bis hier" kann man ohne Zusatzmodule nicht ausdrücken)

Die Frage ist, warum man dem Compiler, der ja hier eigentlich ein
Interpreter ist,
mitteilen soll, was man sich überlegt hat. Wenn ein Skript nicht so arbeitet
wie es
soll, hat man ihm - dem Compiler - offensichtlich das Falsche "mitgeteilt",
und
muss das nun ändern. Dazu bedarf es aber keiner Deklarationen.

Kennst du das Ampelsyndrom bei Autofahrern? Wenn bei jeder Quergasse eine
Ampel stünde, würde bald kein Autofahrer mehr auf den Quervekehr achten;
bei Ausfall einer Ampel wären Unfälle vorprogammiert, weil sich jeder darauf
verlassen würde, dass er, wenn die Ampel nicht rot zeigt, fahren kann, es
würde
niemand mehr (oder zu spät) daran denken, dass es auch Vorrangregeln gibt.
Solche Reaktionen hat man in Ballungsräumen mit hoher Ampelkonzentration
schon vereinzelt beobachtet.

Ähnlich könnte es sich hier verhalten - wer immer brav alles deklariert und
"use strict" und "use warnings" verwendet, könnte annehmen, dass sein Skript
funktionieren muss, sobald er keine Warnungsmeldung mehr bekommt. Und
dass man daher auf ausreichende Tests verzichten kann. Und das ist dann
sicher kein "Best Practice" mehr. Und mir ist es lieber, wenn mir jemand
sagt,
dass er sein Skript vollständig ausgestestet hat, als wenn er mir sagt, er
hat
auch mit "use strict" und "use warnings" keine Meldungen mehr bekommen.

>> Und nur genau das sollte "Best Practice" sein. Der Weg dorthin sollte
>> offen sein und niemandem Praktiken abverlangen, mit denen er nicht
>> glücklich wird.
>
> TMTOWTDI. Perl verlangt von Dir nicht, dass Variablen deklarierst. Unter
> Umständen verlangen es Deine Team-Kollegen.

Naja, bei uns wäre es eher umgekeht. Aber das kann man natürlich nicht
verallgemeinern, das ist mir schon klar.

>>> Welchen Typ soll eine undeklarierte Variable haben? int?
>>
>> Den, den ich ihr zuweise.
>
> Du hast hier den Kontext weggeworfen. In diesem Absatz ging es explizit
> um C.

Na, eigentlich (ursprünglich) ging es um die Sinnhaftigkeit von
Deklarationen
in Perl. Über die Notwendigkeit von Deklarationen in Compilersprachen
sind wir uns ja ohnehin einig.

> Und C ist - im Gegensatz zu Perl - eine statisch typisierte
> Sprache. Der Typ jeder Variable (und jedes Ausdrucks) steht zur
> Compilezeit fest. Eine Analyse, welchen Typ du zuweist, wäre theoretisch
> ohne explizite Deklarationen in C möglich, wenn der gesamte Source-Code
> vorliegt, aber sehr aufwendig. Das hätte sicher die Möglichkeiten einer
> PDP-11 anno 74 überschritten :-).

Wie gesagt: bei Compilersprachen sind Deklarationen unumgänglich und
ich konnte auch stets damit leben. Bei Skriptsprachen empfinde ich sie als
überflüssig, in Perl speziell "our", das IMHO mehr Probleme schafft als
löst. Am ehesten kann ich mich noch mit der Deklaration lexikalischer
Variablen innerhalb von Funktionen und Methoden anfreunden, weil hier
tatsächlich die Gefahr besteht, globale Variable zu überschreiben. Aber
auf die Deklaration _jeder_ Variable in einem Skript werde ich, solange
mir die Wahl freigestellt ist, auch weiterhin verzichten. Und das ist für
mich auch nicht "Best Practice", sondern - und da sind wir wieder am
Anfang - ein neumodische Erscheinung.

LG, Ferry
--

Re: aus dem Kamelbuch

"Ferry Bolhar" writes:

> Peter J. Holzer:
>
> >. Zwar habe ich (wie
> > viele andere, die in den 80ern Programmieren gelernt haben,
> > wahrscheinlich auch) mit BASIC angefangen, das auch keine
> > Variablendeklarationen kannte,
>
> Aber - zumindest die BASICs, die ich kannte - hatten implizite Typen-
> festlegungen in den Namen: X = float, X$ = string und X% = integer, IIRC.
> Also führte zB. ein X = "HALLO" zu einem "Type mismatch", es musste
> X$ = "HALLO" heißen. Und ein ähnliches Schema gab es, wie du ja weiter
> unten schreibst, auch in Fortran.

Und auch bei Perl, nur das wir den Unterschied zwischen Zahlen und
Strings nicht angeben müssen, dafür aber zwischen Skalaren, Arrays und
Hashes (u.a.).

>
> > bin aber relativ bald zu Pascal und dann
> > C übergewechselt. Das sind aber statisch typisierte Sprachen und damit
> > ist eine Deklaration unerlässlich, weil der Typ einer Variablen eben zur
> > Compilezeit feststehen muss und es (zumindest in C) zu viele Typen gibt,
> > um das über Sigils oder Anfangsbuchstaben ("GOD is REAL", wie alte
> > Fortran-Programmierer wissen) festzulegen.
>
> Ja, dass es Deklarationen in Compilersprachen geben muss, ist klar (es muss
> sie ja auch in Assembler geben), aber in Skriptsprachen? Das war ja eben für
> mich immer einer der Vorzüge einer Skriptsprache, das man auf Deklarationen
> verzichten kann.

Warum muss es Deklarationen in Compilersprachen geben? Es spricht ja
nichts dagegen, dass eine Compilersprache etwas ähnliches wie ein SV
verwendet. Nur wenn man optimieren will, muss man Deklarationen
benutzen, damit man ein int sparsam in vier Bytes unterbringen kann
und nicht in (sizeof SV) Bytes unterbringen muss. Oder wenn man
verhindern will, dass für jede Variable erst einmal in einer
Hashtabelle nachgeschaut werden muss, wo sie sich denn im Speicher
befindet.

>
> >> Die vorherige Deklaration von Variablen befreit einen Programmier nämlich
> >> nicht davon, sich zu überlegen, was er tut.
> >
> > Das soll es auch nicht. Die Deklaration dient dazu, dass der
> > Programmierer dem Compiler mitteilen kann, was er sich überlegt hat.
> > (In Perl ist das zugegenermaßen wenig. Mehr als "diese Variable brauche
> > ich von hier bis hier" kann man ohne Zusatzmodule nicht ausdrücken)
>
> Die Frage ist, warum man dem Compiler, der ja hier eigentlich ein
> Interpreter ist,
> mitteilen soll, was man sich überlegt hat. Wenn ein Skript nicht so arbeitet
> wie es
> soll, hat man ihm - dem Compiler - offensichtlich das Falsche "mitgeteilt",
> und
> muss das nun ändern. Dazu bedarf es aber keiner Deklarationen.
>
> Kennst du das Ampelsyndrom bei Autofahrern? Wenn bei jeder Quergasse eine
> Ampel stünde, würde bald kein Autofahrer mehr auf den Quervekehr achten;
> bei Ausfall einer Ampel wären Unfälle vorprogammiert, weil sich jeder darauf
> verlassen würde, dass er, wenn die Ampel nicht rot zeigt, fahren kann, es
> würde
> niemand mehr (oder zu spät) daran denken, dass es auch Vorrangregeln gibt.
> Solche Reaktionen hat man in Ballungsräumen mit hoher Ampelkonzentration
> schon vereinzelt beobachtet.
>
> Ähnlich könnte es sich hier verhalten - wer immer brav alles deklariert und
> "use strict" und "use warnings" verwendet, könnte annehmen, dass sein Skript
> funktionieren muss, sobald er keine Warnungsmeldung mehr bekommt. Und
> dass man daher auf ausreichende Tests verzichten kann. Und das ist dann
> sicher kein "Best Practice" mehr. Und mir ist es lieber, wenn mir jemand
> sagt,
> dass er sein Skript vollständig ausgestestet hat, als wenn er mir sagt, er
> hat
> auch mit "use strict" und "use warnings" keine Meldungen mehr
> bekommen.

Deinen Vergleich aus der Verkehrwelt kann ich nicht in die
Programmierwelt unterbringen. Und ja, natürlich kann man auch mit "use
strict" vollkommen "dysfunktional" programmieren. Wer aber Interesse
an korrekten und wartbaren Code hat, wird "use strict" und geschicktem
Deklarieren benutzen müssen. Ich bin auch sehr traurig darüber, dass
das Deklarieren mittlerweile nur bei einfachen Variablen möglich ist
und nicht mehr bei Hash-Keys, da Pseudo-Hashes in Perl weggefallen
sind.

>
> >> Und nur genau das sollte "Best Practice" sein. Der Weg dorthin sollte
> >> offen sein und niemandem Praktiken abverlangen, mit denen er nicht
> >> glücklich wird.
> >
> > TMTOWTDI. Perl verlangt von Dir nicht, dass Variablen deklarierst. Unter
> > Umständen verlangen es Deine Team-Kollegen.
>
> Naja, bei uns wäre es eher umgekeht. Aber das kann man natürlich nicht
> verallgemeinern, das ist mir schon klar.
>
> >>> Welchen Typ soll eine undeklarierte Variable haben? int?
> >>
> >> Den, den ich ihr zuweise.
> >
> > Du hast hier den Kontext weggeworfen. In diesem Absatz ging es explizit
> > um C.
>
> Na, eigentlich (ursprünglich) ging es um die Sinnhaftigkeit von
> Deklarationen
> in Perl. Über die Notwendigkeit von Deklarationen in Compilersprachen
> sind wir uns ja ohnehin einig.
>
> > Und C ist - im Gegensatz zu Perl - eine statisch typisierte
> > Sprache. Der Typ jeder Variable (und jedes Ausdrucks) steht zur
> > Compilezeit fest. Eine Analyse, welchen Typ du zuweist, wäre theoretisch
> > ohne explizite Deklarationen in C möglich, wenn der gesamte Source-Code
> > vorliegt, aber sehr aufwendig. Das hätte sicher die Möglichkeiten einer
> > PDP-11 anno 74 überschritten :-).
>
> Wie gesagt: bei Compilersprachen sind Deklarationen unumgänglich und
> ich konnte auch stets damit leben. Bei Skriptsprachen empfinde ich sie als
> überflüssig, in Perl speziell "our", das IMHO mehr Probleme schafft als
> löst. Am ehesten kann ich mich noch mit der Deklaration lexikalischer
> Variablen innerhalb von Funktionen und Methoden anfreunden, weil hier
> tatsächlich die Gefahr besteht, globale Variable zu überschreiben. Aber
> auf die Deklaration _jeder_ Variable in einem Skript werde ich, solange
> mir die Wahl freigestellt ist, auch weiterhin verzichten. Und das ist für
> mich auch nicht "Best Practice", sondern - und da sind wir wieder am
> Anfang - ein neumodische Erscheinung.

Da stellt sich bei mir die Frage, wie groß deine Programme sind. Wenn
du nur wenige hundert Zeilen schreibst und nicht auf
(selbstgeschriebene) Module zugreifst, dann kannst du durchaus so
weiter arbeiten. Oder wenn dein Code relativ statisch ist und du kein
Refactoring betreiben musst.

Für meine Anwendungen ist "no strict" kein Thema.

Gruß,
Slaven

--
Slaven Rezic - slaven rezic de

need xpm or ppm output from GD?
http://search.cpan.org/search?mode=module&query=GD::Convert

Re: aus dem Kamelbuch

On 2006-08-29 12:40, Ferry Bolhar wrote:
> Peter J. Holzer:
>
>>. Zwar habe ich (wie
>> viele andere, die in den 80ern Programmieren gelernt haben,
>> wahrscheinlich auch) mit BASIC angefangen, das auch keine
>> Variablendeklarationen kannte,
>
> Aber - zumindest die BASICs, die ich kannte - hatten implizite Typen-
> festlegungen in den Namen: X = float, X$ = string und X% = integer, IIRC.

Ja. So wie Perl den Typ einer Variable über die Sigil feststellt:
$x = scalar, @x = array, %x = hash. Auch in BASIC waren X und X$
unterschiedliche Variablen, so wie in Perl $x und @x unterschiedliche
Variablen sind. Ich sehe da gewisse Ähnlichkeiten (aber es gibt
natürlich auch Unterschiede).

>> bin aber relativ bald zu Pascal und dann
>> C übergewechselt. Das sind aber statisch typisierte Sprachen und damit
>> ist eine Deklaration unerlässlich, weil der Typ einer Variablen eben zur
>> Compilezeit feststehen muss und es (zumindest in C) zu viele Typen gibt,
>> um das über Sigils oder Anfangsbuchstaben ("GOD is REAL", wie alte
>> Fortran-Programmierer wissen) festzulegen.
>
> Ja, dass es Deklarationen in Compilersprachen geben muss, ist klar

Mir nicht. Erstens gibt es keine "Compilersprachen". Jede Sprache kann
man compilieren oder direkt interpretieren. Es gibt nur Sprachen, die
üblicherweise compiliert werden. Zweitens kenne ich genug Sprachen, die
üblicherweise compiliert werden, in denen Deklarationen optional sind
(z. B. FORTRAN, Lisp, Perl, ...), um ein "muss" zu widerlegen.

Das Problem bei Sprachen wie C ist die Menge der Typen. C hat allein 9
Integertypen (seit C99 mindestens 2 mehr) und 3 Floating-Point-Typen,
sowie eine unendliche Menge davon abgeleiteter Typen (über structs,
arrays und pointer). Wenn ich dem Compiler nicht sage, dass x ein
unsigned long sein soll und y ein char[100], kann er es nicht wissen,
außer ich führe irgendwelche irrwitzigen Namenskonventionen (Simonyi,
schau oba!) ein. Wenn ich wie in BASIC, Perl oder Lisp nur eine
Handvoll Typen habe, kann man das über einfache Namenskonventionen (z.B.
Sigils) machen oder der Compiler kann in vielen Fällen den Typ sogar
selbständig erkennen.

> (es muss sie ja auch in Assembler geben), aber in Skriptsprachen? Das
> war ja eben für mich immer einer der Vorzüge einer Skriptsprache, das
> man auf Deklarationen verzichten kann.

"Make simple things simple" ist sicherlich ein Designkriterium von
Scriptsprachen (wie auch immer man das definieren mag).


>>> Die vorherige Deklaration von Variablen befreit einen Programmier nämlich
>>> nicht davon, sich zu überlegen, was er tut.
>>
>> Das soll es auch nicht. Die Deklaration dient dazu, dass der
>> Programmierer dem Compiler mitteilen kann, was er sich überlegt hat.
>> (In Perl ist das zugegenermaßen wenig. Mehr als "diese Variable brauche
>> ich von hier bis hier" kann man ohne Zusatzmodule nicht ausdrücken)
>
> Die Frage ist, warum man dem Compiler, der ja hier eigentlich ein
> Interpreter ist, mitteilen soll, was man sich überlegt hat.

Zwei Gründe:

1) Damit der Compiler guten Code erzeugen kann.

2) Damit der Compiler Widersprüche in meinem Gedankengang erkennen und
mich darauf aufmerksam machen kann. Wenn ich schon weiß, dass eine
bestimmte Variable nur ganzzahlige Werte von 1 bis 9999 annehmen kann
und ich das dem Compiler mitteilen kann, dann kann der Compiler Alarm
schreien, wenn ich dann dieser Variable irgendwann den Wert "Hallo"
oder -17.4 zuzuweisen versuche. So erkenne ich den Fehler sofort, und
muss ihn nicht erst mühsam suchen, wenn irgendeinem User aufgefallen
ist, dass die Ergebnisse "irgendwie komisch" ausschauen.


> Wenn ein Skript nicht so arbeitet wie es soll, hat man ihm - dem
> Compiler - offensichtlich das Falsche "mitgeteilt", und muss das nun
> ändern. Dazu bedarf es aber keiner Deklarationen.

Die Deklaration ermöglicht aber dem Compiler in vielen Fällen, den
Fehler zu finden. Sieh es als erste Testsuite.


> Ähnlich könnte es sich hier verhalten - wer immer brav alles deklariert und
> "use strict" und "use warnings" verwendet, könnte annehmen, dass sein Skript
> funktionieren muss, sobald er keine Warnungsmeldung mehr bekommt.

Das ist eine Falle, in die Programmieranfänger gerne tappen (ich war
ein paar Jahre an den Sysprog-Übungen auf der TU Wien beteiligt). Sie
glauben, wenn der Compiler nichts mehr am Programm auszusetzen hat, muss
es richtig sein. Dass der Compiler nicht wissen kann, was das Programm
eigentlich tun soll, merken sie spätestens beim zweiten Übungsbeispiel
:-).

> Und dass man daher auf ausreichende Tests verzichten kann. Und das ist
> dann sicher kein "Best Practice" mehr. Und mir ist es lieber, wenn mir
> jemand sagt, dass er sein Skript vollständig ausgestestet hat, als
> wenn er mir sagt, er hat auch mit "use strict" und "use warnings"
> keine Meldungen mehr bekommen.

Wenn mir jemand sagt, dass er das Script vollständig ausgestestet hat,
dann werde ich ihn entweder für naiv oder einen Lügner halten. Wenn er
mir sagt, dass er für jedes Requirement mindestens einen Testcase hat
und die Testcase 100% des Codes abdecken, bin ich beeindruckt.
use strict und use warnings gehören IMHO zum Grundvokabular des Testens.
Man findet damit einen Haufen relativ trivialer Fehler. Ja, natürlich
kann man diese Fehler auch anders finden, aber wozu soll ich stundenlang
suchen, wenn sie der Compiler in Sekundenbruchteilen findet? Ich bin ein
fauler Mensch. Und ungeduldig bin ich auch.


> Wie gesagt: bei Compilersprachen sind Deklarationen unumgänglich und
> ich konnte auch stets damit leben. Bei Skriptsprachen empfinde ich sie als
> überflüssig, in Perl speziell "our", das IMHO mehr Probleme schafft als
> löst.

Mir hat es bisher noch keine Probleme bereitet, allerdings verwende ich
es kaum. my ist meistens vollkommen ausreichend.

> Am ehesten kann ich mich noch mit der Deklaration lexikalischer
> Variablen innerhalb von Funktionen und Methoden anfreunden, weil hier
> tatsächlich die Gefahr besteht, globale Variable zu überschreiben.

Ah, aber woher soll der Compiler wissen, ob eine Variable lokal oder
global ist, wenn Du es ihm nicht sagst?

sub foo {
for ($i = 0; $i < 10; $i++) {
print "$i\n";
}
}

sub bar {
$i = 5 unless $i;
print "$i\n";
}

foo(); bar();

Was sollte dieses Script ausgeben?

In Perl sind undeklarierte Variablen implizit global. Es gibt hier somit
eine globale Variable $i, die beim Aufruf von bar() den Wert 10 hat.

Es wäre aber durchaus eine sinnvolle Intepretation, dass das $i in foo
lokal zur Schleife sein soll, während das $i in bar ziemlich sicher eine
globale Variable sein soll (zumindest muss ihre Lebensdauer über einen
Aufruf von bar hinausgehen, sonst wäre das erste Statement ziemlich
sinnlos).

Wenn nun also, wie Du schreibst, die Gefahr besteht, dass ich mit der
lokalen Variable $i in foo die globale Variable $i, die in bar verwendet
wird, überschreibe, und mir der Compiler dabei helfen soll, diese Gefahr
zu erkennen, dann muss ich $i *immer* deklarieren, denn sonst kann er
die beiden oben skizzierten Möglichkeiten nicht unterscheiden. Zumindest
wüsste ich nicht wie.

Und da ich gerne lokale Variable habe (für globale Variable bin ich zu
blöd), muss ich meine Variablen deklarieren.


> Aber auf die Deklaration _jeder_ Variable in einem Skript werde ich,
> solange mir die Wahl freigestellt ist, auch weiterhin verzichten.

Wenn Du gerne die Arbeit machst, die Dir der Compiler abnehmen kann,
bitte sehr.


> Und das ist für mich auch nicht "Best Practice", sondern - und da sind
> wir wieder am Anfang - ein neumodische Erscheinung.

"Globale Variablen sind Böse(TM)" war schon zum Beginn meiner
Studienzeit ein alter Hut, und das ist jetzt 20 Jahre her. Als
fürchterlich neumodisch kann ich das nicht sehen.

hp

--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: aus dem Kamelbuch

Ferry Bolhar wrote:
> Richtig. Aber wer definiert "wartbar"?

Das ist recht einfach zu definieren. Man sollte es jemandem der den
geschriebenen Code irgendwann verstehen und ändern muß möglichst
einfach machen. (Es gibt aber sicher unendlich viele andere und
schlauere Definitionen.)

> Wie schon erwähnt, komme ich aus einem Bereich, wo es in
> Skriptsprachen nicht möglich war (und ist), Variable zu deklarieren.
> Und daher hätten auch meine Kollegen, die es ebenfalls nicht anders
> kennen, keine Probleme, meine Skripts "zu warten" (und umgekehrt).

Du hast mich falsch verstanden. Es geht nicht darum ob es zu einem
Problem wird, oder gar unmöglich ist eine Software zu warten, sondern
darum, dass explizite Deklarationen (bzw. das Fordern selbiger) das
ganze einfacher machen. (Warum haben Peter und Slaven ja schon
erörtert.)

> Wir tun uns eher schwer, Programme zu warten, in denen erst
> ellenlang Variable deklariert werden, bevor man auf die erste echte
> Anweisung stößt. Wir haben PL/I-Progamme, da ist das Verhältnis
> Deklararionen:Code etwa 50:50. Und _DAS_ würde ich als schwer
> wartbar bezeichnen.

Warum? Wenn du die Deklarationen partout nicht sehen willst, dann
blende sie aus. Wenn dein Editor das nicht kann, solltest du dir
vielleicht einen anderen Editor suchen. ;o)
Und gerade wenn es so viele unterschiedliche Variablen gibt, möchte
ich die nicht jedes mal manuell auf Überschneidungen überprüfen
müssen. Vor allem nicht wenn die Programmiersprache Automatismen
dafür bereitstellt.

> Es ist auch OK, wenn jemand in Perl jede Variable vor der Benutzung
> mit "my" bzw. "our" deklariert, wenn er meint, dadurch besser Code
> zu schreiben.

Der Code muß sich durch die Deklarationen nicht ändern und der
Compiler kann trotzdem offensichtliche Fehler melden.


lg,
daniel