in reply to Re^12: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
in thread What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff

This node falls below the community's threshold of quality. You may see it by logging in.
  • Comment on Re^13: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
  • Select or Download Code

Replies are listed 'Best First'.
Re^14: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by GrandFather (Saint) on Oct 11, 2020 at 21:03 UTC

    In Perl you can write:

    $i = 0 if $i < 0;

    which reads nicely to me. That makes the conditional statement obvious and there is no clutter of brackets or parenthesis. In C++ (why would you ever use C?) I would write:

    if (i < 0) i = 0;

    I never append a statement like a wart I was trying to hide on the end of a conditional line. The important principle here is that important stuff should be at the start of a line because stuff at the end of lines doesn't exist. If the controlled statement is appended to the end of the line it gets lost. As an indented line on its own the controlled statement is visible and its relationship to the conditional statement is clear.

    Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

      For completeness, note that Perl Best Practices, chapter 6 (Control Structures), "Use block if, not postfix if" argues that postfix-if does not scale as well as block-if, and is harder to comprehend (except in simple cases). I agree, especially with the scaling argument. Always using block-if has made code reviews more enjoyable for me over many years because there are fewer changed lines of code to review whenever you just add an extra statement to a block-if (compared to more violently restructuring the code from postfix-if to block-if).

      In chapter 4 (Values and Expressions), "Don't mix high- and low-precedence booleans", Conway recommends using the low precedence and and or operators for flow of control, for example:

      open(my $fh, '<', $file) or die "error opening '$file': $!";
      while reserving && and || for logical expressions (not flow of control) for example:
      if ($x > 5 && $y < 10) ...
      Following this simple rule over the years has made the code easier to understand at a glance, at least for me.

        I'm lazy. if is shorter and requires no translation compared to and so it's a double win. The rawest Perl newbie, or indeed interlopers from most B derived languages, should have little difficulty understanding the if variant. The and variant with its somewhat subtle use of precedence and evaluation side effects is significantly more of a maintenance burden.

        Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond