FAQ
My Code:
use strict ;
use warnings ;

chomp($input = <STDIN>) ;

I compile this but has a error. say:Globla symbol "@input" requires
explicit package name at...
What should i do?

Search Discussions

  • Shlomi Fish at Sep 13, 2011 at 12:34 pm
    Hello William,

    On Mon, 12 Sep 2011 20:05:38 -0700 (PDT)
    William wrote:
    My Code:
    use strict ;
    use warnings ;

    chomp($input = <STDIN>) ;

    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 = <STDIN>);

    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’m a true Klingon geek‐warrior! And a true Klingon geek
    warrior ALWAYS bottom‐posts.

    Please reply to list if it's a mailing list post - http://shlom.in/reply .
  • William at Sep 13, 2011 at 5:40 pm

    On 9月13日, 下午8时33分, shlo...@shlomifish.org (Shlomi Fish) wrote:
    Hello William,

    On Mon, 12 Sep 2011 20:05:38 -0700 (PDT)

    William wrote:
    My Code:
    use strict ;
    use warnings ;
    chomp($input = <STDIN>) ;
    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 = <STDIN>);

    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’m a true Klingon geek‐warrior! And a true Klingon geek
    warrior ALWAYS bottom‐posts.

    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.
  • John Delacour at Sep 13, 2011 at 9:31 pm
    At 15:33 +0300 13/09/2011, Shlomi Fish wrote:

    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
  • Chris Stinemetz at Sep 13, 2011 at 9:39 pm

    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);
    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
  • John Delacour at Sep 13, 2011 at 9:57 pm

    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
  • Uri Guttman at Sep 14, 2011 at 3:34 am
    "JD" == John Delacour writes:
    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 -------
  • Paul Johnson at Sep 14, 2011 at 12:28 pm

    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 letter
    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 problems in
    software development, and that the length of a variable name should reflect
    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 small
    amount of information; 7 ± 2 items according to Miller, but more recently
    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 obscure
    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 its
    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 names,
    this would fill our short-term memory requiring us to go back and check what
    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 rather
    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 queue,
    $c for a customer, $n for a count and so forth. The problems start to occur
    when we have a customer and a context, for example, and at that point having a
    variable named $c is more if a hindrance than a help. That's when you would
    want $cust and $cxt, or $customer and $context depending on the size of their
    scope.

    --
    Paul Johnson - paul@pjcj.net
    http://www.pjcj.net
  • Uri Guttman at Sep 14, 2011 at 3:52 pm
    "PJ" == Paul Johnson writes:
    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 -------
  • Shawn H Corey at Sep 14, 2011 at 4:18 pm

    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
  • Rob Dixon at Sep 14, 2011 at 8:20 pm

    On 14/09/2011 16:51, Uri Guttman wrote:
    "PJ" == Paul Johnson<paul@pjcj.net> writes:
    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
  • Uri Guttman at Sep 14, 2011 at 8:30 pm
    "RD" == Rob Dixon writes:
    RD> On 14/09/2011 16:51, Uri Guttman wrote:
    "PJ" == Paul Johnson<paul@pjcj.net> writes:
    >>
    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 -------
  • Rob Dixon at Sep 14, 2011 at 9:50 pm

    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
  • Uri Guttman at Sep 15, 2011 at 12:58 am
    "RD" == Rob Dixon writes:
    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 -------
  • Brandon McCaig at Sep 15, 2011 at 3:19 am

    On Wed, Sep 14, 2011 at 8:57 PM, Uri Guttman wrote:
    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/80957c72518411bd61070d1b9a026d61.jpg


    --
    Brandon McCaig <http://www.bamccaig.com/> <bamccaig@gmail.com>
    V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
    Castopulence Software <http://www.castopulence.org/> <bamccaig@castopulence.org>
  • Uri Guttman at Sep 15, 2011 at 3:40 am
    "BM" == Brandon McCaig writes:
    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 -------
  • Shawn H Corey at Sep 15, 2011 at 1:36 pm

    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
  • William at Sep 14, 2011 at 1:02 pm

    On Sep 14, 5:39 am, chrisstinem...@gmail.com (Chris Stinemetz) wrote:
    ...For more information see:
    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);
    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
  • Jim Gibson at Sep 14, 2011 at 9:30 pm
    On 9/14/11 Wed Sep 14, 2011 5:04 AM, "William" <lilijreey@gmail.com>
    scribbled:
    On Sep 14, 5:39 am, chrisstinem...@gmail.com (Chris Stinemetz) wrote:
    ...For more information see:
    #!/usr/local/bin/perl
    use strict;
    $a = 1;
    $b = 2;
    print qq($a, $b\n);
    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'.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupbeginners @
categoriesperl
postedSep 13, '11 at 3:07a
activeSep 15, '11 at 1:36p
posts19
users10
websiteperl.org

People

Translate

site design / logo © 2022 Grokbase