in reply to Coding style: truth of variable name

Sometimes, you can solve the problem by avoiding the situation completely: 
for my $dir (glob '*/') {

[download]
I'm not sure how it works on MSWin, so maybe more portably 
for my $dir (grep -d, glob '*') {

[download]

The second case is different. I'd probably declare two subroutines: 

sub load_from_path {
    my ($module_path) = @_;
    # etc.
}

sub load_from_name {
    my ($module_name) = @_;
    my $module_path = ...;
    load_from_path($module_path);
}

[download]
I mean, it's not the responsibility of the "load" subroutine to convert the module name to its path. It's the caller's responsibility to know what they have and what they want to do with it.

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

Replies are listed 'Best First'.
Re^2: Coding style: truth of variable name
by perlancar (Hermit) on Apr 19, 2020 at 02:00 UTC

    True in the above cases. Bad examples then :)

    How about the common cases where a function needs to validate its input. Do you assign the pre-validated content to the variable first, or do you assign it to something else first and then to the final variable after it's validated?

[reply]

      perlancar:

      In the case of input validation, I usually let the variable name express the intent then validate the value into submission before doing the work:

      sub frob_file {
    my $frobbable_filename = shift;
    die "Error" if !-e $frobbable_filename or -d $frobbable_filename;
    die "Nope!" if not_frobbable($filename);

    ... frob file ...
}

      [download]

      In other cases when the variable isn't so clear but it will be clear shortly, I'll often use $t or $tmp for the placeholder. Then I'll give it a name or pass the data off to a better-named thing:

      sub zap_the_thing {
    my $t = shift;
    my @files_to_zap;

    if (-d $t) {
       zap_dir($t);
    }
    else {
       push @files_to_zap, $t;
    }

    ... yadda ...

    zap_files(@files_to_zap);
}

      [download]

      I don't think $t or $tmp is a great name, but finding good names is hard. I use it so that I can look at it and dispose of it ASAP.

      Frequently I find I can't name something well the first time I encounter or use it. So I come up with my best guess of the name and use it. Then, when it feels like the name is wrong, and I find it doesn't fit, I do one of two things: If I have a better name in mind, I'll rename it. Sometimes, though, I can't think of a better name, so I instead give it a prefix of 'z' to "call it out". That way, when I revisit the code, I know I need a better name. Not perfect, not even good, but it usually gets me by. Yet I still wind up with stuff like:

      # ?NEED GOOD NAME?
# If a group (Row, Col, Blk) has only one slot for a particular value,
# solve that cell.
sub solve_v_in_only_one_cell_in_R_C_B {
    my ($self, $GEN) = @_;

      [download]

      an atrocity which came directly off my screen from last nights session.

      ...roboticus

      When your only tool is a hammer, all problems look like your thumb.

[reply]
[d/l]
[select]

      I read unvalidated into one variable and then put it into a validated variable when I call the validation routine. The variables differ only in their prefix. I learned this from https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/, which is still worth reading. Here's a pseudocode example:

      my $inv_data = get_input();
my $val_data = val_from_inv($inv_data);

      [download]

      Regards,

      John Davies

[reply]
[d/l]

In Section Seekers of Perl Wisdom