in reply to dereferencing question

The whole 'saving 1 character' thing isn't really the space saving that people think it is. I started programming in the 70's, and even then we didn't worry about how much space a source code file took up, and that was with disks that were measured in 10-20 megabytes. That's storage -- data transmission isn't something anyone worries about -- I just finished a three way video call that ran for half an hour. I have no idea how much bandwidth that took, but it completely overwhelms any space saving that might have been realized by 'saving a character'.

Finally, my favorite reason: writing software targets two different goals: Communicating efficiently and accurately with a computer, and communicating clearly with future developers (that may include you when you have to go back over your code to understand what you were thinking when you wrote it). The computer only cares if the code compiles and runs. If the source code is clear and legible, future developers will quickly be able to understand how it works. If there's a little obfuscation, that's not going to affect the computer, but it's definitely going to slow things down with reader comprehension.

The print command is expecting a scalar; if you pass it an array, you may not get what you're expecting:

DB<1> $array = [qw(a b c)]; DB<2> $hash = { a => 1, b => 2, c => 3 }; DB<3> print $array->[2]; c DB<4> print $hash->{a}; 1 DB<5> print @$array[2]; c DB<6> print %$hash{a}; a1 DB<7>
So -- I imagine that the last print statement didn't output what you were expecting. And those second two print statements are less clear than the first two. The form $array->[2] is much clearer than @$array[2] or $$array[2] (from ikegami, above). I would even argue that 'array' is a misnomer, because it's actually an array_ref (a reference to an array).

Clarity in writing software is paramount. Having to wade through some 'clever code' can be a real challenge; it's worse when it's your own code, because someone wise once said that you have to be twice as smart to debug something as you do to write it in the first place.

Alex / talexb / Toronto

For a long time, I had a link in my .sig going to Groklaw. I heard that as of December 2024, this link is dead. Still, thanks to PJ for all your work, we owe you so much. RIP Groklaw -- 2003 to 2013.

Replies are listed 'Best First'.
Re^2: dereferencing question
by cavac (Prior) on Jan 22, 2025 at 12:17 UTC

    communicating clearly with future developers

    And also search tools, code prettyfiers and the occasional perl script to mass-update existing code bases for more modern Perl idioms¹. The more unique (and standardized across the whole codebase) a construct is, the easier it is to find, even with non-regex searches.

    It's basically the same reason for naming a variable @customers instead of @c: Easier to understand, and much more important, easier to find.


    ¹ Converting to sub signatures, which (mostly) worked and saved me many days of manual editing.

    PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
    Also check out my sisters artwork and my weekly webcomics

      The only time I use single character variable names like $k is when the scope is going to be something really small like five to ten lines. For example,

      foreach my $k ( keys %DBhandles ) { $DBhandles{ $k }{ sth }->finish; $DBhandles{ $k }{ dbh }->disconnect; }
      And yes, I could minimize that to just using $_ instead of $k, but I try to never use that special variable, because it requires extra effort for the reader.

      Alex / talexb / Toronto

      For a long time, I had a link in my .sig going to Groklaw. I heard that as of December 2024, this link is dead. Still, thanks to PJ for all your work, we owe you so much. RIP Groklaw -- 2003 to 2013.

        Yeah, $_ (especially the implicit version) is something to generally avoid. It's not only harder to read and understand, but it's also easy to mess up a program when you have to re-shuffle some logic.

        As for single-character iterators, i mostly use them on C-style for loops. $i, $x, $y are my favourites, with $i for general stuff. $x and $y are always sensible choices when iterating over the pixels of an image, plus there aren't that many other variable names (english words) that start with an "x" or "y" that also make sense in a cash register application.

        PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
        Also check out my sisters artwork and my weekly webcomics