My Code:
use strict ;
use warnings ;
chomp($input =
I compile this but has a error. say:Globla symbol "@input" requires
explicit package name at...
What should i do?
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
Hello William,
On Mon, 12 Sep 2011 20:05:38 -0700 (PDT)
William
> My Code:
> use strict ;
> use warnings ;
>=20
> chomp($input =3D
>=20
> I compile this but has a error. say:Globla symbol "@input" requires
> explicit package name at...
Well, you didn't copy-and-paste the error correctly, but I recognise it. Th=
is
is an anachronistic error (and unfortunately very common) that means that y=
ou
should declare your variables using "my":
chomp(my $input =3D
For more information see:
http://perl.plover.com/FAQs/Namespaces.html
Regards,
Shlomi Fish
--=20
------------------------------------------------------------ -----
Shlomi Fish http://www.shlomifish.org/
Interview with Ben Collins-Sussman - http://shlom.in/sussman
I may be a geek, but Iâ=99m a true Klingon geekâ=90warrior! And a=
true Klingon geek
warrior ALWAYS bottomâ=90posts.
Please reply to list if it's a mailing list post - http://shlom.in/reply .
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
On 9æ=8813æ=A5, ä¸å8æ=B633å=86, shlo...@=
shlomifish.org (Shlomi Fish) wrote:
> Hello William,
>
> On Mon, 12 Sep 2011 20:05:38 -0700 (PDT)
>
> William
> > My Code:
> > use strict ;
> > use warnings ;
>
> > chomp($input =3D
>
> > I compile this but has a error. say:Globla symbol "@input" requires
> > explicit package name at...
>
> Well, you didn't copy-and-paste the error correctly, but I recognise it. =
This
> is an anachronistic error (and unfortunately very common) that means that=
you
> should declare your variables using "my":
>
> Â Â Â Â chomp(my $input =3D
>
> For more information see:
>
> http://perl.plover.com/FAQs/Namespaces.html
>
> Regards,
>
> Â Â Â Â Shlomi Fish
>
> --
> ------------------------------------------------------------ -----
> Shlomi Fish    http://www.shlomifish.org/
> Interview with Ben Collins-Sussman -http://shlom.in/sussman
>
> I may be a geek, but Iâ=99m a true Klingon geekâ=90warrior! And=
a true Klingon geek
> warrior ALWAYS bottomâ=90posts.
>
> Please reply to list if it's a mailing list post -http://shlom.in/reply.
thanks, It's pretty inconvenient.,for Almost vary variables is private
in code block, these must use my operator.
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
At 15:33 +0300 13/09/2011, Shlomi Fish wrote:
>...For more information see:
>
>http://perl.plover.com/FAQs/Namespaces.html
Useful article.
Now can you explain why I get no error with this little routine? -
#!/usr/local/bin/perl
use strict;
$a = 1;
$b = 2;
print qq($a, $b\n);
However as soon as I progress to $c or $aa or any number of other
denominations, I do get the expected error.
Just in case the aqnomaly was due to my software I tested it also in
the command line and got the same result:
$ perl <<'END';
use strict;
$a = 1;
$b = 2;
print qq($a, $b\n);
END
JD
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
>
>> ...For more information see:
>>
>> http://perl.plover.com/FAQs/Namespaces.html
>
> Useful article.
>
> Now can you explain why I get no error with this little routine? -
>
> =A0 =A0 =A0 =A0#!/usr/local/bin/perl
> =A0 =A0 =A0 =A0use strict;
> =A0 =A0 =A0 =A0$a =3D 1;
> =A0 =A0 =A0 =A0$b =3D 2;
> =A0 =A0 =A0 =A0print qq($a, $b\n);
>
From Learning Perl book:
In some circumstances, $a and $b won't need to be declared, because
they're used internally by sort. So if you're testing this feature,
use other variable names than those two. The fact that use strict
doesn't forbid these two is one of the most frequently reported
non-bugs in Perl.
HTH,
Chris
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
At 16:39 -0500 13/09/2011, Chris Stinemetz wrote:
>From Learning Perl book:
>
>In some circumstances, $a and $b won't need to be declared, because
>they're used internally by sort. So if you're testing this feature,
>use other variable names than those two. The fact that use strict
>doesn't forbid these two is one of the most frequently reported
>non-bugs in Perl.
Hmm. I wonder if Randall would explain why he considers it a non-bug
for them to escape the pragma outside the context of sort. I must
say I have only discovered it just now because I generally use more
descriptive names for variables, but it seems to me very bug-like.
JD
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
>>>>> "JD" == John Delacour
JD> At 16:39 -0500 13/09/2011, Chris Stinemetz wrote:
>>> From Learning Perl book:
>>
>> In some circumstances, $a and $b won't need to be declared, because
>> they're used internally by sort. So if you're testing this feature,
>> use other variable names than those two. The fact that use strict
>> doesn't forbid these two is one of the most frequently reported
>> non-bugs in Perl.
JD> Hmm. I wonder if Randall would explain why he considers it a non-bug
JD> for them to escape the pragma outside the context of sort. I must say
JD> I have only discovered it just now because I generally use more
JD> descriptive names for variables, but it seems to me very bug-like.
nope. it is done that way for speed. perl passes the pairs of sort args
in $a and $b in the globals rather than on @_ as it is much
faster. since sort is a speed thing they did it this way. it is well
known that those vars are excepted from strict and why when they are
seen outside sort, reviewers will admonish it. you can always do my $a
and it will be just a lexical. but single letter var names are bad in
general (other than MAYBE $i and $j, etc. for indexing).
here is another good reason to stay aways from single letter var
names. they are hard to search for as other vars which start with those
letters will also be found.
uri
--
Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
------------ Perl Developer Recruiting and Placement Services -------------
----- Perl Code Review, Architecture, Development, Training, Support -------
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
On Tue, Sep 13, 2011 at 11:34:34PM -0400, Uri Guttman wrote:
> here is another good reason to stay aways from single letter var
> names. they are hard to search for as other vars which start with those
> letters will also be found.
This may be the worst argument I have ever heard against using single let=
ter
variable names. Please don't let your code be held hostage to the tools =
you
are using, especially if there are better tools available.
My own take on variable names is that naming is one of the hardest proble=
ms in
software development, and that the length of a variable name should refle=
ct
the length of the scope in which it is visible. A single letter variable=
name
is fine in a small loop, for example. A larger scope would call for a
correspondingly larger variable name.
The rationale for this is that our short-term memory can store only a sma=
ll
amount of information; 7 =B1 2 items according to Miller, but more recent=
ly
thought to be 3 or 4 "chunks". When reading or writing code, excess text=
such
as unnecessary comments, excessive punctuation and even long names can ob=
scure
the meaning of the code making it harder to reason about. If a common
variable in a small scope can be given a short name, that variable and it=
s
purpose can be stored in our short-term memory for the duration of our
concentration on that scope. For larger scopes, where there are more nam=
es,
this would fill our short-term memory requiring us to go back and check w=
hat
the short name actually referred to, negating the benefit of having less
cluttered code.
Naturally, this is also the reason why the name must be descriptive rathe=
r
than merely long, and certainly shouldn't be misleading.
And as with other names, a single letter variable name should reflect its
purpose as much as possible, to further aid our understanding; $q for a q=
ueue,
$c for a customer, $n for a count and so forth. The problems start to oc=
cur
when we have a customer and a context, for example, and at that point hav=
ing a
variable named $c is more if a hindrance than a help. That's when you wo=
uld
want $cust and $cxt, or $customer and $context depending on the size of t=
heir
scope.
--=20
Paul Johnson - paul@pjcj.net
http://www.pjcj.net
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
On Sep 14, 5:39=A0am, chrisstinem...@gmail.com (Chris Stinemetz) wrote:
> >> ...For more information see:
>
> >>http://perl.plover.com/FAQs/Namespaces.html
>
> > Useful article.
>
> > Now can you explain why I get no error with this little routine? -
>
> > =A0 =A0 =A0 =A0#!/usr/local/bin/perl
> > =A0 =A0 =A0 =A0use strict;
> > =A0 =A0 =A0 =A0$a =3D 1;
> > =A0 =A0 =A0 =A0$b =3D 2;
> > =A0 =A0 =A0 =A0print qq($a, $b\n);
>
> From Learning Perl book:
>
> In some circumstances, $a and $b won't need to be declared, because
> they're used internally by sort. So if you're testing this feature,
> use other variable names than those two. The fact that use strict
> doesn't forbid these two is one of the most frequently reported
> non-bugs in Perl.
>
> HTH,
>
> Chris
Hi Chris:
what's the function of qq :p
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
>>>>> "PJ" == Paul Johnson
PJ> On Tue, Sep 13, 2011 at 11:34:34PM -0400, Uri Guttman wrote:
>> here is another good reason to stay aways from single letter var
>> names. they are hard to search for as other vars which start with those
>> letters will also be found.
PJ> This may be the worst argument I have ever heard against using
PJ> single letter variable names. Please don't let your code be held
PJ> hostage to the tools you are using, especially if there are better
PJ> tools available.
show me a tool that can search for single letter names cleanly and with
little effort as compared to longer names. also this isn't the only
reason, just one of several.
PJ> My own take on variable names is that naming is one of the hardest
PJ> problems in software development, and that the length of a
PJ> variable name should reflect the length of the scope in which it
PJ> is visible. A single letter variable name is fine in a small
PJ> loop, for example. A larger scope would call for a
PJ> correspondingly larger variable name.
PJ> And as with other names, a single letter variable name should
PJ> reflect its purpose as much as possible, to further aid our
PJ> understanding; $q for a queue, $c for a customer, $n for a count
PJ> and so forth. The problems start to occur when we have a customer
PJ> and a context, for example, and at that point having a variable
PJ> named $c is more if a hindrance than a help. That's when you
PJ> would want $cust and $cxt, or $customer and $context depending on
PJ> the size of their scope.
and $q or $c is still a poor name even in a tight scope. it tells
nothing to the reader about the content of the variable. it is just a
placeholder for the author. you might as well just use $_ everywhere you
can. names need to convey information about variable usage. single
letter ones have very little information.
uri
--
Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
------------ Perl Developer Recruiting and Placement Services -------------
----- Perl Code Review, Architecture, Development, Training, Support -------
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
On 11-09-14 11:51 AM, Uri Guttman wrote:
> show me a tool that can search for single letter names cleanly and with
> little effort as compared to longer names. also this isn't the only
> reason, just one of several.
ViM. Put the cursor on the variable and press *
Also: press # to search backward.
> and $q or $c is still a poor name even in a tight scope. it tells
> nothing to the reader about the content of the variable. it is just a
> placeholder for the author. you might as well just use $_ everywhere you
> can. names need to convey information about variable usage. single
> letter ones have very little information.
Agreed. You should only use single-character names for well-known
mathematical formula. Or where you don't have a choice, like `sort`.
--
Just my 0.00000002 million dollars worth,
Shawn
Confusion is the first step of understanding.
Programming is as much about organization and communication
as it is about coding.
The secret to great software: Fail early & often.
Eliminate software piracy: use only FLOSS.
"Make something worthwhile." -- Dear Hunter
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
On 14/09/2011 16:51, Uri Guttman wrote:
>>>>>> "PJ" == Paul Johnson
>
> PJ> On Tue, Sep 13, 2011 at 11:34:34PM -0400, Uri Guttman wrote:
> >> here is another good reason to stay aways from single letter var
> >> names. they are hard to search for as other vars which start with those
> >> letters will also be found.
>
> PJ> This may be the worst argument I have ever heard against using
> PJ> single letter variable names. Please don't let your code be held
> PJ> hostage to the tools you are using, especially if there are better
> PJ> tools available.
>
> show me a tool that can search for single letter names cleanly and with
> little effort as compared to longer names. also this isn't the only
> reason, just one of several.
>
> PJ> My own take on variable names is that naming is one of the hardest
> PJ> problems in software development, and that the length of a
> PJ> variable name should reflect the length of the scope in which it
> PJ> is visible. A single letter variable name is fine in a small
> PJ> loop, for example. A larger scope would call for a
> PJ> correspondingly larger variable name.
>
> PJ> And as with other names, a single letter variable name should
> PJ> reflect its purpose as much as possible, to further aid our
> PJ> understanding; $q for a queue, $c for a customer, $n for a count
> PJ> and so forth. The problems start to occur when we have a customer
> PJ> and a context, for example, and at that point having a variable
> PJ> named $c is more if a hindrance than a help. That's when you
> PJ> would want $cust and $cxt, or $customer and $context depending on
> PJ> the size of their scope.
>
> and $q or $c is still a poor name even in a tight scope. it tells
> nothing to the reader about the content of the variable. it is just a
> placeholder for the author. you might as well just use $_ everywhere you
> can. names need to convey information about variable usage. single
> letter ones have very little information.
Uri we are all privileged with your thoughts on variable naming. My last
attempt to say that perhaps you weren't always right wrong resulted in a
personal attack saying "you had that blowup a few months ago. are you
doing that again?" Given that you choose not even to punctuate American
English properly I find your position less than convincing.
Also, as I posted before, if you forbid even the very minimum of $i, $n,
$x, $y, $z, $h, $m, $s then your advice is destructive bigotry.
Please cease.
Rob
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
>>>>> "RD" == Rob Dixon
RD> On 14/09/2011 16:51, Uri Guttman wrote:
>>>>>>> "PJ" == Paul Johnson
>>
PJ> On Tue, Sep 13, 2011 at 11:34:34PM -0400, Uri Guttman wrote:
>> >> here is another good reason to stay aways from single letter var
>> >> names. they are hard to search for as other vars which start with those
>> >> letters will also be found.
>>
PJ> This may be the worst argument I have ever heard against using
PJ> single letter variable names. Please don't let your code be held
PJ> hostage to the tools you are using, especially if there are better
PJ> tools available.
>>
>> show me a tool that can search for single letter names cleanly and with
>> little effort as compared to longer names. also this isn't the only
>> reason, just one of several.
>>
PJ> My own take on variable names is that naming is one of the hardest
PJ> problems in software development, and that the length of a
PJ> variable name should reflect the length of the scope in which it
PJ> is visible. A single letter variable name is fine in a small
PJ> loop, for example. A larger scope would call for a
PJ> correspondingly larger variable name.
>>
PJ> And as with other names, a single letter variable name should
PJ> reflect its purpose as much as possible, to further aid our
PJ> understanding; $q for a queue, $c for a customer, $n for a count
PJ> and so forth. The problems start to occur when we have a customer
PJ> and a context, for example, and at that point having a variable
PJ> named $c is more if a hindrance than a help. That's when you
PJ> would want $cust and $cxt, or $customer and $context depending on
PJ> the size of their scope.
>>
>> and $q or $c is still a poor name even in a tight scope. it tells
>> nothing to the reader about the content of the variable. it is just a
>> placeholder for the author. you might as well just use $_ everywhere you
>> can. names need to convey information about variable usage. single
>> letter ones have very little information.
RD> Uri we are all privileged with your thoughts on variable naming. My last
RD> attempt to say that perhaps you weren't always right wrong resulted in a
RD> personal attack saying "you had that blowup a few months ago. are you
RD> doing that again?" Given that you choose not even to punctuate American
RD> English properly I find your position less than convincing.
again, you attack personally and not about the topic.
RD> Also, as I posted before, if you forbid even the very minimum of $i, $n,
RD> $x, $y, $z, $h, $m, $s then your advice is destructive bigotry.
i said $i and $j are generally fine. in some cases maybe $x and $y. but
those are not nearly as many vars as all the others. the vast majority
of vars should not be named with single letter names. it is a rule with
some exceptions. i prefer to emphasize the rule here in order for
newbies to learn that picking good names is important. and single letter
var names are in general a poor choice.
RD> Please cease.
nah, you first! :)
uri
--
Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
------------ Perl Developer Recruiting and Placement Services -------------
----- Perl Code Review, Architecture, Development, Training, Support -------
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
On 9/14/11 Wed Sep 14, 2011 5:04 AM, "William"
scribbled:
> On Sep 14, 5:39=A0am, chrisstinem...@gmail.com (Chris Stinemetz) wrote:
>>>> ...For more information see:
>>=20
>>> =A0 =A0 =A0 =A0#!/usr/local/bin/perl
>>> =A0 =A0 =A0 =A0use strict;
>>> =A0 =A0 =A0 =A0$a =3D 1;
>>> =A0 =A0 =A0 =A0$b =3D 2;
>>> =A0 =A0 =A0 =A0print qq($a, $b\n);
>>=20
>=20
> Hi Chris:
> what's the function of qq :p
I am not Chris, but I can answer your question. 'qq' is a quote-operator
that interprets its argument in a double-quote context, interpolating the
values of variables and escape sequences and returning a scalar value. Thus=
,
qq($a, $b\n) is equivalent to "$a, $b\n".
qq() is often used to improve readability. One advantage is that embedded
double-quote characters do not need to be escaped. For example, qq(") is
equivalent to "\"", but more readable.
See 'perldoc perlop' and search for 'Quote and Quote-like Operators'.
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
On 14/09/2011 21:30, Uri Guttman wrote:
>
>> Uri we are all privileged with your thoughts on variable naming. My last
>> attempt to say that perhaps you weren't always right wrong resulted in a
>> personal attack saying "you had that blowup a few months ago. are you
>> doing that again?" Given that you choose not even to punctuate American
>> English properly I find your position less than convincing.
>
> again, you attack personally and not about the topic.
"you had that blowup..." was less than topical :/
(Or are you talking about your poor English, which is no more personal
than your poor Perl naming requirements?)
>> Also, as I posted before, if you forbid even the very minimum of $i, $n,
>> $x, $y, $z, $h, $m, $s then your advice is destructive bigotry.
>
> i said $i and $j are generally fine. in some cases maybe $x and $y. but
> those are not nearly as many vars as all the others. the vast majority
> of vars should not be named with single letter names. it is a rule with
> some exceptions. i prefer to emphasize the rule here in order for
> newbies to learn that picking good names is important. and single letter
> var names are in general a poor choice.
If your intention is to insist on meaningful identifiers then I am with
you wholeheartedly, but rejecting single-character names is a crude
filter than has a lot of obvious exceptions. As yet another example,
quadratic equations are far from rare in practice, so would you really
have me rewrite the following?
sub quad_roots {
my ($a, $b, $c) = @_;
my $desc = $b * $b - 4 * $a * $c;
return if $desc < 0;
$desc = sqrt $desc;
return (-$b + $root_desc) / (2 * $a), (-$b - $root_desc) / (2 * $a);
}
>> Please cease.
>
> nah, you first! :)
I wanted you to stop setting up rules here without saying that they are
your own fabrication. I think you are misleading the beginners here by
implying that the laws you lay down are accepted practice.
What is it that you would have me cease, apart from disagreeing with you?
Rob
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
>>>>> "RD" == Rob Dixon
RD> On 14/09/2011 21:30, Uri Guttman wrote:
>>
>>> Uri we are all privileged with your thoughts on variable naming. My last
>>> attempt to say that perhaps you weren't always right wrong resulted in a
>>> personal attack saying "you had that blowup a few months ago. are you
>>> doing that again?" Given that you choose not even to punctuate American
>>> English properly I find your position less than convincing.
>>
>> again, you attack personally and not about the topic.
RD> "you had that blowup..." was less than topical :/
it was topical as your (self admitted) blowup happened here. and it
caused a small ruckus until you calmed down.
RD> (Or are you talking about your poor English, which is no more personal
RD> than your poor Perl naming requirements?)
my good engrish is fine very well!
>>> Also, as I posted before, if you forbid even the very minimum of $i, $n,
>>> $x, $y, $z, $h, $m, $s then your advice is destructive bigotry.
>>
>> i said $i and $j are generally fine. in some cases maybe $x and $y. but
>> those are not nearly as many vars as all the others. the vast majority
>> of vars should not be named with single letter names. it is a rule with
>> some exceptions. i prefer to emphasize the rule here in order for
>> newbies to learn that picking good names is important. and single letter
>> var names are in general a poor choice.
RD> If your intention is to insist on meaningful identifiers then I am with
RD> you wholeheartedly, but rejecting single-character names is a crude
RD> filter than has a lot of obvious exceptions. As yet another example,
RD> quadratic equations are far from rare in practice, so would you really
RD> have me rewrite the following?
it isn't a crude filter. it is a solid rule of thumb. a useful
guideline. where did i say once that all single letter vars are out? i
said there are exceptions but few and very localized. my bigger point
which you are ignoring is that by far the larger number of vars need
proper names so using single letter names is an exception. the point is
to notice that single letter names are not useful in general. in
specific cases they could be. you haven't addressed the scope of the
number of names out there.
a classic generic rule for this is don't do this unless you know when
not to.
uri
--
Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
------------ Perl Developer Recruiting and Placement Services -------------
----- Perl Code Review, Architecture, Development, Training, Support -------
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
On Wed, Sep 14, 2011 at 8:57 PM, Uri Guttman
> it was topical as your (self admitted) blowup happened here. and it
> caused a small ruckus until you calmed down.
I'd say you're both out to lunch on this. I don't even recall this
subject so if I even read the affected threads then I obviously didn't
think it was worth acknowledging or remembering. Sometimes people put
their foot in their mouth (or on their keyboard, as the case may be).
It sounds like a private matter so I see little reason to bring it up
now (especially repeatedly, if my memory is correct that it's not the
first thread that I've seen it re-surface on). and if it persists then
all you can really do is ignore that person's posts.
> my good engrish is fine very well!
Personally I agree that it's very sloppy to write without capitals.
It's lazy and annoying to read. Capitals are a part of the English
language syntax. I don't claim to write perfect English, but I do try.
Something as simple as capitalizing the first letter of a sentence is
primary! You learn it in like the first or second grade. It's not like
the shift key is overly difficult for you to reach for either. It's
something a Perl programmer obviously must cope with unless they've
somehow found a special Perl-oriented keyboard or special OS
configuration that makes $ and @ and & (and all of the other shifted
characters common in Perl) possible to type with a single key...
Somebody so pedantic about code should certainly apply himself more in
typing human language for public consumption, IMHO.
> it isn't a crude filter. it is a solid rule of thumb. a useful
> guideline. where did i say once that all single letter vars are out? i
> said there are exceptions but few and very localized. my bigger point
> which you are ignoring is that by far the larger number of vars need
> proper names so using single letter names is an exception. the point is
> to notice that single letter names are not useful in general. in
> specific cases they could be. you haven't addressed the scope of the
> number of names out there.
Rob did a very good job of describing this. The amount of detail
required for a variable name is proportional to the scope that the
variable is visible to. A two line subroutine usually does not require
a 10 or 20 character lexical variable. The variable's purpose is
usually obvious. It serves no practical purpose and only serves to
waste limited human memory and processing power to use a descriptive
name. With self-describing code it's often obvious what the variable
represents. At least in the code that I write. Adding detail to that
is just redundant and verbose. There's a reason a --verbose option is
the norm versus a --brief option. :) We normally don't need or want
extra information. We can get by with the bare minimum most of the
time, especially when we're already familiar with what we're dealing
with. We'll let you know if we need more detail, thanks. :) If we do
need more detail then we only need it the once. We don't need you to
bring it up every time we come across something. Or if we do then
you've already Done Something Wrong(tm).
As elite as Uri may or may not be within the Perl community[1], you
can search online for references of Linus Torvalds[2] suggesting very
terse variable names whenever a more descriptive name isn't necessary.
Whether or not you subscribe to elitism, I think most can agree that
Mr. Torvalds is probably universally considered more elite than Uri.
So I guess that's a trump. I don't stalk Linus so unfortunately I'm
unaware if he has since changed his mind, but if he had I think it
would only serve to demonstrate that such a topic is very subjective
and people do indeed change their minds on the subject over time,
sometimes even going back and forth. There is no definite right or
wrong answer. It's not black and white.
I'm perfectly open to discussing such a topic and actually find it
rewarding to do so. It's both fun and often educational to learn of
other people's experiences and possibly expand your own horizons with
regards to a subject, whether subjective or not. What completely ruins
the discussion though is when somebody joins in, insisting to have The
One True Answer(tm), without being able to provide an unquestionable
proof for it, and insisting that they're right and you're wrong. You
might get away with this if the discussion is taking place on your own
personal mailing list or discussion board, or for a project thereof,
but if it's just a public discussion and you're not universally
considered "god" by the community then I think it's only fair to add a
little bit of humility to your posts and try to remain friendly and
open to discussion.[3] It may well be true that in your own personal
experience single-character variable names are difficult to
understand, but then in my experience it may be exactly the opposite.
So then which one is universally right? Perhaps neither.
So that it's clear I have no interest in having any kind of beef with
Uri, or anyone else on this list for that matter. I'm here to learn
and have fun, and maybe, if I'm lucky, help out now and then. Making a
few friends or acquaintances along the way would be icing on the cake.
[1] I personally find it very petty when Uri mentions his work as a
Perl "recruitment agent" (for lack of a better description right now)
and implies that he'll never consider you as a potential candidate
with regards to that because of your opinion on a subjective topic.
That's not even a relevant qualification, IMHO; I bet there are a few
thousands, if not millions, of people doing that job that don't even
know the first thing about software development. Go consult
http://thedailywtf.com/ for some fun stories about people being hired
in senior programming roles without even knowing the very basics of
programming. :-X
[2] Sorry, Linus, for dragging your name into this.
[3] http://static.allegro.cc/image/cache/8/0/80957c72518411bd610 70d1b9a026d61.jpg
--
Brandon McCaig
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
>>>>> "BM" == Brandon McCaig
BM> [1] I personally find it very petty when Uri mentions his work as a
BM> Perl "recruitment agent" (for lack of a better description right now)
BM> and implies that he'll never consider you as a potential candidate
BM> with regards to that because of your opinion on a subjective topic.
BM> That's not even a relevant qualification, IMHO; I bet there are a few
BM> thousands, if not millions, of people doing that job that don't even
BM> know the first thing about software development. Go consult
BM> http://thedailywtf.com/ for some fun stories about people being hired
BM> in senior programming roles without even knowing the very basics of
BM> programming. :-X
and you're not being petty bringing that up? :)
my point there is that i do judge perl and other skills
professionally. not a hobby, not on this list, etc. i get paid for my
opinions about the quality of candidates. i review their code, talk the
them about it, listen to what they say, how they take the critique,
etc. it all factors in. my views on coding style and rules are mine but
developed over 38 years of coding. i beat linus on that and i have done
things he hasn't done so that isn't a useful comparison (a silly one
IMO). so getting back to this. if i suggest something or offer an idea
here, you can take it or leave it. you can discuss it in a logical way
or attack me directly or my posting style. i choose to say that one way
is more how i want to see and i support in candidates i recommend. the
other is not something that i want my clients to see in their
developers. that is my job, separating the professionals from the
kiddies. and if you act like a kiddie and get all hurt because i
disagree with your ideas, that is your issue and i won't be helping you
out as much. you need to separate ideas from the person. i do that all
the time. if you can't see that, i can't help there either. i will
attack your ideas if i think they deserve it. i will not attack the
person unless they attack me or other people.
and getting back to the subject at hand, single letter var names. you
and rob seem to keep forgetting i didn't say never use single letter
names. i said the vast majority of vars don't want them so focus on
those. and try to keep away from single char names. get it? try to keep
away from the is the idea. you want to convey information to the reader
of the code. single letter names convey no information unless they are
cultural standards like $i. and those are not used as often as you all
seem to think. as i said think about the thousands of names you need to
pick and use - how many are $i and related? a tiny fraction. so why even
support their use except for the few allowable cases? the logic railed
against this is weak and emotional and not in the interest of good
coding. that is my goal, better coding for all. single letter names IN
GENERAL are a bad coding idea. i yelled again for emphasis. no one seems
to get that point.
and i am off this thread. all replies will be redirected to
/dev/null. let's move on.
uri
--
Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
------------ Perl Developer Recruiting and Placement Services -------------
----- Perl Code Review, Architecture, Development, Training, Support -------
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
On 11-09-14 11:18 PM, Brandon McCaig wrote:
> Personally I agree that it's very sloppy to write without capitals.
I find it sloppy for people whose first language is English not to do
their best. Many readers of this list do not have English as a their
first language and the best way to improve theirs is to read
well-written English. In other words, it's incumbent on native-English
speakers to do their best so others may learn from it.
--
Just my 0.00000002 million dollars worth,
Shawn
Confusion is the first step of understanding.
Programming is as much about organization and communication
as it is about coding.
The secret to great software: Fail early & often.
Eliminate software piracy: use only FLOSS.
"Make something worthwhile." -- Dear Hunter
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/