Re^14: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff

In Perl you can write:

$i = 0 if $i < 0;
[download]

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;
[download]

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

Comment on Re^14: 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^15: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff (Use block if not postfix if References) by eyepopslikeamosquito (Archbishop) on Oct 11, 2020 at 23:55 UTC
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': $!";` [download] while reserving `&&` and `\|\|` for logical expressions (not flow of control) for example: `if ($x > 5 && $y < 10) ...` [download] Following this simple rule over the years has made the code easier to understand at a glance, at least for me.	[reply] [d/l] [select]
Re^15: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff by tobyink (Canon) on Oct 11, 2020 at 21:05 UTC
Or: `$i < 0 and $i = 0;` [download] In either case, no brackets, no braces, no parentheses necessary. toby döt ink	[reply] [d/l]
Re^16: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff by GrandFather (Saint) on Oct 11, 2020 at 21:59 UTC
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	[reply] [d/l] [select]
Re^17: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff by tobyink (Canon) on Oct 12, 2020 at 00:27 UTC
`# Original if (X) { Y; } # Postfix if Y if X; # Low-precedence and X and Y;` [download] Low precedence `and` has the advantage that it is ordered "X, Y" instead of "Y, X". toby döt ink	[reply] [d/l] [select]