in reply to bug or curly bracket hell?
That is some really stinky code. The worst smell comes from #use strict. Uncommenting that line and cleaning up all your variable declarations would highlight the elsif/else/elsif issue noted by haukex. On the basis of that alone this can not be the code that is generating the error you report because this code does not compile and therefore can't run to produce the error described!
Another stinky thing is long lists of lines like $worksheet->write($rowCount1 + 1, 0, $t[0]);.
while ($sthrows > $Count) { would be much better written for my $row (1 .. sthrows) {.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^2: bug or curly bracket hell?
by MoodyDreams999 (Scribe) on Jan 13, 2023 at 16:25 UTC | |
| [reply] |
by hippo (Archbishop) on Jan 13, 2023 at 16:45 UTC | |
"Global symbol "%s" requires explicit package name" Can you give me some tips on fixing that? You have chopped off the last part of the error message and that was the bit which explains how you can fix it.
🦛 | [reply] [d/l] |
by MoodyDreams999 (Scribe) on Jan 13, 2023 at 19:29 UTC | |
okay lets say I have this code to access a server/database and I have repeating variables and these are the repeating errors I have on strict. Variable "$VARDB_DATABASE" is not imported AT PROJECT.PL LINE 43. I get this for the other variables as well then Global symbol "$VARDB_DATABASE" requires explicit package name AT PROJECT LINE 43. Keep in mind this works with out strict for me. (paragraph)
| [reply] [d/l] |
by Anonymous Monk on Jan 13, 2023 at 20:36 UTC | |
by MoodyDreams999 (Scribe) on Jan 13, 2023 at 21:52 UTC | |
| |
by GrandFather (Saint) on Jan 13, 2023 at 23:02 UTC | |
First off: 'code smells' are coding styles that are fragile or hard to maintain (probably because they are hard to read). use strict helps address some forms of code smell if used sensibly. One thing that can make a huge difference is to ensure variables are used in the smallest sensible scope - strict helps that by telling you where an undeclared variable is first used. A very closely related technique is to initialise scalar variables (variables that start with $) where they are declared. Sometimes array and hash variables can be usefully initialised where they are declared too, but often they are used to accumulate entries in following code and don't need an explicit initialisation value at declaration (they are born empty). The golden rule: Always use strictures (use strict; use warnings; - see The strictures, according to Seuss). Strictures, especially strict, tell you about things that are easy to get wrong and hard to find, like changing the spelling of an identifier. Using lexical variables (variables declared with my) limits their scope to the enclosing block (within the enclosing { } pair) which helps in understanding how variables are used and avoids misusing variables. Fixing a bad smell can often end up with a jolly good clean out of the whole fridge to everyone's benefit. Adopting the use of strictures is a good start to cleaning up smelly code.
Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
| [reply] [d/l] |
by Bod (Parson) on Jan 14, 2023 at 01:11 UTC | |
Adopting the use of strictures is a good start to cleaning up smelly code Absolutely seconded! I resisted at first but since following the teaching wise monks, my code has been less smelly, giving me an easier and more pleasant coding life. | [reply] |
by MoodyDreams999 (Scribe) on Jan 24, 2023 at 23:03 UTC | |
| [reply] [d/l] |
by kcott (Archbishop) on Jan 24, 2023 at 23:46 UTC | |
by GrandFather (Saint) on Jan 25, 2023 at 02:10 UTC | |
| |
by Anonymous Monk on Jan 24, 2023 at 23:40 UTC |