Global symbol "$buidTarget" requires explicit package name

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Global symbol "$buidTarget" requires explicit package name by hippo (Bishop) on May 13, 2020 at 15:21 UTC
That's because you have mis-spelled `$buildTarget` by omitting the letter `l`. Using strict has saved your bacon.	[reply] [d/l] [select]
Re^2: Global symbol "$buidTarget" requires explicit package name by Fletch (Bishop) on May 13, 2020 at 17:10 UTC
Don't feel bad because even those of us who've been doing this for ages will still occasionally sit there and blank out despite the error message explicitly telling what's wrong. It's only obvious after you've bothered to show it to someone else. And you read it again. And then sit down and actually read it. And then there's the "Derp." If you ever have a debugging problem like this where you're not seeing the problem, go walk off for 5-10 minutes and do something unrelated. When you come back and look at it fresh it can help. The cake is a lie. The cake is a lie. The cake is a lie.	[reply]
Re^3: Global symbol "$buidTarget" requires explicit package name by BillKSmith (Monsignor) on May 13, 2020 at 19:04 UTC
Another equally strange, but often effective technique is called Rubber_duck_debugging. Bill	[reply]
Re^3: Global symbol "$buidTarget" requires explicit package name by Aaronrp (Scribe) on May 15, 2020 at 02:42 UTC
Back in the '80s when I was using IBM BASICA, I got stuck for three weeks because I typed `F0R X = 1 TO MAX` at the start of a very long line with multiple statements, instead of `FOR X = 1 TO MAX` I do not know when syntax highlighting was invented but it's great stuff.	[reply] [d/l] [select]
Re^2: Global symbol "$buidTarget" requires explicit package name by Anonymous Monk on May 18, 2020 at 05:15 UTC
thank you!	[reply]
Re: Global symbol "$buidTarget" requires explicit package name by karlgoethebier (Abbot) on May 13, 2020 at 21:29 UTC
Shit happens and #MeToo. As already mentioned. My very best error was when I typed `use Net::SNMP` instead of `use Net::SMTP` many years ago and wondered why the stuff I programmed didn’t work. I wrote an email to the author and received a very friendly reply. You may also consider Pair Programming 🤪😎🦆 Best regards «The Crux of the Biscuit is the Apostrophe» `perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'`Help	[reply] [d/l] [select]
Re^2: Global symbol "$buidTarget" requires explicit package name by perlancar (Hermit) on May 14, 2020 at 01:04 UTC
This gives me an idea for a perl critic policy that warns against declaring package names, subroutine names, variable names, or even hash keys that are prone to misspellings. Wondering what metrics should I use.	[reply]
Re^3: Global symbol "$buidTarget" requires explicit package name by hippo (Bishop) on May 14, 2020 at 08:10 UTC
I happened upon this list of common misspellings just the other day. Not convinced that many of them would turn up frequently in code anyway, but it might be one place to start. Maybe different policies for different (natural) languages would be easiest?	[reply]
Re^3: Global symbol "$buidTarget" requires explicit package name by AnomalousMonk (Archbishop) on May 14, 2020 at 04:27 UTC
... metrics ... Anything that's spelled. That's what I usually mispel. :) Give a man a fish: `<%-{-{-{-<`	[reply] [d/l]
Re^4: Global symbol "$buidTarget" requires explicit package name by karlgoethebier (Abbot) on May 14, 2020 at 15:38 UTC
Re^3: Global symbol "$buidTarget" requires explicit package name by karlgoethebier (Abbot) on May 14, 2020 at 07:55 UTC
I’m dreaming since years about something like this: `use Acme::LapsusLinguae;`. If I wrote `use Cuke;` but meant `use Nose;` I would get an compile time error with some in-depth explanation. «The Crux of the Biscuit is the Apostrophe» `perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'`Help	[reply] [d/l] [select]
Re^3: Global symbol "$buidTarget" requires explicit package name by perlfan (Vicar) on May 19, 2020 at 08:46 UTC
Interesting. This might give you some ideas, https://stackoverflow.com/questions/2979174/how-do-i-compute-the-approximate-entropy-of-a-bit-string. Or maybe use a password strength checker. If it's too great of a password, maybe it's a terrible variable/package/hashkey name.	[reply]
Re^3: Global symbol "$buidTarget" requires explicit package name by Anonymous Monk on May 14, 2020 at 18:27 UTC
Maybe a policy that prohibits variables within a given minimum Levenshtein distance? That might work regardless of language.	[reply]


Your skill will accomplish what the force of many cannot
	PerlMonks