Re: Legacy code question
by haukex (Archbishop) on May 13, 2019 at 14:11 UTC
|
Is there any advantage to using an array over a string here?
I guess it depends on how the variable is used afterwards - if there are additional values being pushed onto the array, it might make sense. It's just assigning a single value to the array; personally I would have written my @sqltt = (<<EOF); to make it explicit that yes, I meant to assign a single value to this array. But if the code then goes on to use $sqltt[0] everywhere, and especially if it doesn't add elements to the array, then it would definitely have been better to just use a plain scalar in the first place.
use warnings;
use strict;
use Data::Dump;
my @sqltt = <<EOF;
Hello,
World!
EOF
dd @sqltt;
__END__
"Hello,\nWorld!\n"
Minor update to wording. | [reply] [Watch: Dir/Any] [d/l] [select] |
|
Nothing is added to it, only use is as \@sqltt. I'm thinking this is a "do not do" thing.
Thank you!
| [reply] [Watch: Dir/Any] |
|
Nothing is added to it, only use is as \@sqltt. I'm thinking this is a "do not do" thing.
It still depends on the surrounding code - if it's being passed to a function that expects an arrayref, then some form of such is required, either my @sqltt = (<<EOF); ... func(\@sqltt), my $sqltt = [<<EOF]; ... func($sqltt), or my $sqltt = <<EOF; ... func([$sqltt]) would be needed (which one is a matter of taste), and "do not do" wouldn't necessarily apply. Context matters :-)
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: Legacy code question
by davido (Cardinal) on May 13, 2019 at 15:20 UTC
|
The code is using an array to hold a single element at this particular line. Later in the code it is possible that an array is desirable for some other reason; something gets added, or a subroutine called with a funky prototype, or it is otherwise convenient.
Often when examining legacy code you'll find artifacts of the past. Perhaps an array is not all that useful at this point in the code as it exists today, but maybe seven years ago an array was exactly what was needed. Things that needed to change got changed, and things that continued to work didn't get changed.
Or it's just dumb. That's usually the last explanation to assume, though. More often than not either it is this way for a reason now, or is this way because of the code's evolution over time. But dumb is a perfectly reasonable explanation too, and not necessarily an indictment on the developer. I find myself having to forgive myself sometimes, too. The best explanation I have is that I must have been focusing on some other aspect of the problem and didn't notice I had left an inelegant construct laying around as I iterated through the process of crafting a solution.
| [reply] [Watch: Dir/Any] |
|
While I agree philosophically with you and haukex, I have seen quite a fair bit of code in the wild “written” by users like bigup401. Code that never made sense, was written without use strict, often worked by side-effect or accident or only on a narrow subset of possible input, and is full of no-ops left-over from writing code by cut-and-paste testing.
| [reply] [Watch: Dir/Any] [d/l] |
|
| [reply] [Watch: Dir/Any] [d/l] |
|
|
| [reply] [Watch: Dir/Any] |
Re: Legacy code question
by thanos1983 (Parson) on May 13, 2019 at 14:36 UTC
|
Hello Zenzizenzizenzic,
Just to add something minor here that maybe it will help you to understand a bit more EOF. The actual string EOF it is an indication string that helps you to understand that is the end of your file.
You can define anything as a name e.g. (example of code taken from fellow Monk code haukex):
#!/usr/bin/perl
use strict;
use warnings;
use Data::Dump;
my @sqltt = <<THANOS;
Hello,
World!
THANOS
dd @sqltt;
__END__
$ perl test.pl
"Hello,\nWorld!\n"
Hope this minor part helps you understand more about EOF. In generally I prefer reading files line by line, but this is me.
BR / Thanos
Seeking for Perl wisdom...on the process of learning...not there...yet!
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
The actual string EOF it is an indication string that helps you to understand that is the end of your file. ... I prefer reading files line by line ... [emphasis added]
I think it's important to point out that the EOF identifier as used in the OPed code example has nothing to do with the end-of-file condition or reading an entire file into an array. Rather, it is an arbritrary identifier defined to mark the end of a here document. (I think you understand this perfectly well since you use the THANOS identifier in exactly this way in the code example you give, but I want to clarify this point for any novice monk who might happen upon this thread. :)
Give a man a fish: <%-{-{-{-<
| [reply] [Watch: Dir/Any] [d/l] [select] |
Re: Legacy code question
by LanX (Saint) on May 13, 2019 at 14:33 UTC
|
| [reply] [Watch: Dir/Any] [d/l] |