Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: Ternary operators: a hinderance, not a help

by xdg (Monsignor)
on Aug 09, 2005 at 16:32 UTC ( [id://482295]=note: print w/replies, xml ) Need Help??


in reply to Ternary operators: a hinderance, not a help

If it's used to enhance readability, I'm in favor. Look at your example -- 7 lines of code vs 1 line of code. As long as the tests and predicates are short, single line constructs, I think the vertical space savings of the ternary operator are worthwhile, even when chained.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

  • Comment on Re: Ternary operators: a hinderance, not a help

Replies are listed 'Best First'.
Re^2: Ternary operators: a hinderance, not a help
by Tanalis (Curate) on Aug 09, 2005 at 18:10 UTC
    Agreed, for that example.

    As I state in the OP, however, my point about readability and clarity is concerned more with more complex constructs, of which that example is not one :)

    Vertical space savings are all well and good, but not at the expense of readability. Chained/cascading ternaries quickly lose readability, especially when combined with other code elements.

      I think that what you may be missing is that vertical space savings often enhance readability in terms of making it possible to see the whole forest at once.

      In the same vein, I've seen (mostly beginning C++) people say that printf-formatted strings are too much like line noise, and everything should really be formatted through the expressive cout format, with operators to change the number of digits of precision, etc.

      The same people might well complain about pack. The common lisp community often fields complaints about how terribly obscure the syntax is to format.

      The point is that compressing stuff that's not terribly important to understanding the whole improves understanding of the code overall. Good code should read like stuff you want to read, and my eyes glaze over with too much pointless verbosity. (Usually, my eyes glazing is a sign that the code I'm reading suffers from severe cut-and-paste and really needs to be refactored to deal with multiple cases in a more generic fashion.)

      You've obviously encountered several bad uses of the ?: operator. Allow me to present at least one good one:

      my $numspells = ($doDeanStuff ? 1 : 0) + ($doSeamusStuff ? 1 : 0) + ($doHarryStuff ? 2 : 0) # Harry's stuff takes multipl +e spells + ($doRonStuff ? 1 : 0) + ($doSeverusStuff ? 5 : 0); # it's really complicated print "Budget for this incantation is $numspells spells\n";
      Now in this case I'm sure you could do:
      my $numspells = 0; $numspells += 1 if ($doDeanStuff); $numspells += 1 if ($doSeamusStuff); $numspells += 2 if ($doHarryStuff); # Harry's stuff takes multiple sp +ells $numspells += 1 if ($doRonStuff); $numspells += 5 if ($doSeverusStuff); # it's really complicated
      But I think that the first version is easier - or at least, faster - to read. (more whitespace per bit of meaning) And code that's faster to read is more likely to get read in full before someone makes changes to it.

      (Yeah, I'm just getting around to reading book 6 now)

      -- @/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/; map{y/X_/\n /;print}map{pop@$_}@/for@/
      As I state in the OP, however, my point about readability and clarity is concerned more with more complex constructs, of which that example is not one :)
      I got the impression the OP condemned all use of ?:. If your opinion is "use ?: when that's readable, use if/then/else when that is", you and I agree, because that's what I do. I use ?: when I find that more readable if/then/else, otherwise, I use if/then/else.

      Chained/cascading ternaries quickly lose readability, especially when combined with other code elements.
      So do chained/cascading if/then/else constructs. Or nested loops, or nested indices.

      Your original example, I would write either as:

      my $number = $logical_test ? $value : 0;
      or
      my $number = $value; $number = 0 unless $logical_test;
      or
      my $number = 0; $number = $value if $logical_test;
      depending whether I want to stress the default value of $number. (I might use one of the latter two if $logical_test is expected to have a particular value, and it not having it is an exception, I use the former line if $logical_test could go both ways).
      If $logical_test is 0 if it's false, I might even write it as:
      my $number = $logical_test && $value;

      I wouldn't easily write:

      my $number; if ($logical_test) { $number = $value; } else { $number = 0; }
      as it assigns an initial value to $number in a different scope than its declaration - IMO, that doesn't score bonus points when it comes to readability. It's also 7 lines instead of 1, although it can easily be shortened to:
      my $number; if ($logical_test) {$number = $value} else {$number = 0}
      But still, it's three lines. And worse, both blocks have two thirds of their tokens in common - which just shouts "factor out, factor out". Which would lead to:
      my $number = do {if ($logical_test) {$value} else {0}};
      But then I prefer:
      my $number = $logical_test ? $value : 0;

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://482295]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (6)
As of 2024-04-24 10:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found