$x = 8 if $x == 7;
[download]

$x = 0
    unless $x == 7;
$x = 8
    if $x == 7;

# ... or maybe ternary operator? ...

$x = $x == 7 ? 8 : 0;
[download]

I like the ternary also instead of using braces. Less noise.

But to help me make sense of the statement when I (or someone else) look at it later on, I use multiple lines as in:

$x =
    $x == 7
        ? 8
        : 0;
[download]

Thus, if you don't speak fluent "precedence", this structure does all the work. (Even bordering on "it's right when it's beautiful"?)

The greatest fear of that operator comes from chaining. It's deceptively cool looking to use, so occasionally folks will do something like this (C, Java, Perl, it doesn't matter....)

$x = (y == z) 
     ?  (a == c)  ? foo (a,c)
                  : bar (y,c)
     :  (a == b)  ? baz (a,y)
                  : zap (y,y);
[download]

Identation helps, but there are still cases when a nested if-comb can be more readable.

$x = 8
    if $x == 7;
$x = 0
    if not $x == 7;
[download]

But that will always do two tests. If the test is expensive, or done a lot of times, it's less efficient.

But what is worse is that it's wrong. The original code ends with x being 8 if it was originally 7. Your code ends with $x being 0, all the time.

Abigail

Personally, I've always used braces in my C code, even for one-line 'blocks'. And I've used C longer than I know Perl.

OTOH, I don't go through code and apply braces. I find that as silly as C programmers who reduce a 'then' or 'else' part to one line, and then take the trouble of removing braces.

Abigail

It also doesn't create a scope, but I don't know how costly entering and leaving a scope in C is, so it might not matter.

IIRC, C89 doesn't do scope at anything less than a single function (which is why you have to declare all your variables at the top of your function). I believe C99 introduced the much tighter lexical scoping used in Perl and Java (i.e., you can declare variables inside a block and they disappear at the end of the block). Given C's almost non-existant run time environment, I would imagine that the cost is done entirely at compile time.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

Nope. C has always allowed you to declare your variables immediately after the opening brace. I.e., if (a < 5) { int t; ... } is and always has been (to my knowledge) legal C.

duff

In C/Java/etc, not using braces on multi-line if's with identation can lead to maintainance problems.

before:

if (x>3)
   foo()
[download]

then someone will-undoubtedly screw up like this:

if (x>3)
   foo()
   bar()
[download]

the requirement of braces is a GoodThing (TM).

So if you are writing short statements in C without braces, it's best to use the ternary operator or keep things on the same line:

(x>3) ? foo() : bar();
[download]

OR (less elegantly)

if (x>3) foo();
else bar();
[download]

As this prevents the "ignored brace" error if you don't get in the habit of skipping braces. In practice though, using braces in all cases is best. This means write your C one lines WITH braces.

if (x>3> { foo(); }
[download]

Subject to other controvery is whether opening braces can go at the same line as functions and loops. GNU "C" coding style says yes for loops, no for functions. (I think).

Perl tends to allow a coder to be more stylistic with coding convention, in fact, it tends to encourage it. But having strict rules on braces (everything is a BLOCK) goes a long way to keeping things orderly.

then someone will-undoubtedly screw up like this:

if (x>3)
   foo()
   bar()
[download]

That point was *really* driven home in one of the first C++ programming classes I ever took at school. The professor made a big thing of making sure we *always* used braces even though you didn't have to. I can still picture him waving his hands at the front of the classroom "down the road, someone will want to add something and will forget to add braces. Tears of frustration will ensue because you can't figure out why the code broke."

Good advice methinks.

-- vek --

And no doubt one of the many reasons Larry chose to bypass the errors and use blocks everywhere but in modifiers, but made the modifiers look suitably different by putting the conditional after the statement that nobody would fall prey to this mistake.



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

then someone will-undoubtedly screw up like this:

if (x>3)
   foo()
   bar()
[download]

Why don't you say somebody will undoubtably screw it up like this:

if (x > 3)
   Hello computer!  Please execute the program on my floppy disk now!!
+  Thank you!
[download]

Is it really too much to ask to say that programmers should know what their own code does? Maybe it's just me, but I think it's not.

Will Perl6 give us back the C syntax?

Being Lazy, I prefer the C syntax.

which only saves you a single character; unlike in C the semicolon in Perl separates statements, while in C it terminates statements. So, in C you write:

if (COND) STATEMENT;
[download]

in Perl you write:

if (COND) {STATEMENT}
[download]

Will Perl6 give us back the C syntax?

Extremely unlikely, considering the promotion blocks have made in perl6, and the fact parenthesis around the condition will be optional. In perl6, you can write:

if COND {STATEMENT}
[download]

which is one character less than the equivalent C syntax. (Well, this isn't quite true if you look at white space as well).

Abigail

I didnt see this mentioned already so ill say it here: Dangling else!

if ($x==7) 
   if ($x==8)
     $x=0
else
  $x=7
[download]

Which way to parse this? Is the else for the inner or outer if? Well, there are rules to disambiguate that are typical, I believe the else goes with the innermost if by convention for instance. But overall the simplest solution is to do away with the problem entirely. By saying that the result of a loop or conditional is ALWAYS a block you never have the problems that you encounter by saying it may be a statement OR a block.

And no, I bet you a hundred bytes that this wont change a bit. Larry was wearing his real smart hat when he made this rule up. Using statement modifiers he provided the statement form, and the rest uses the block form. They look different a bit, but thats the idea, they do slightly different things and thus they should look different.

Of course, in perl6, you'd wish your parsing of if statements was as simple as dangling elses. In perl6:

my %foo;
if !%foo{die} {print "Yes"};   # Prints yes.
if !%foo {die} {print "Yes"};  # dies.
[download]

Larry was wearing his real smart hat when he made this rule up.

Oh, he was, when he designed perl1 to perl5. But he's making up for it with his significant whitespace rules in perl6.

Abigail

Well, I dont use the extra whitespace as you do, but I have to say ive become quite accustomed to the parens required around an if. *shrug* Perl6 is a while before it makes into my production enviornment, so im not too fussed.

But this whitespace issue really gets your goat eh Abigail? Heh.



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

Never bugged me a bit. It's no different from:

$x = 8 if $x == 7;
[download]

Which is valid Perl. What Perl won't allow you to do is run an else/elsif after that:

$x = 0 else;
[download]

Just won't work. If anything, the Perl form is worse because the conditional is showing up in code after the statement, but is being executed first. As shown above, it's also less flexible.

AFAIK, it works in Java and C because those languages define that a statement comes after an if/else/while/whatever, and that a block is a statement which clusters one or more other statements. Perl's parsing rules are, umm, different.

In perl, it's counter-intuitive to say something like:

do_something() if(COND);
[download]

Why is it counter-intuitive in Perl? It might be counter-intuitive for you, but that doesn't mean you can generalize that. It may be counter-intuitive for you to say I use my umbrella if it rains, but that doesn't make it counter-intuitive to say it in English. For the majority of the English speakers, it's not counter-intuitive to say "Effect if condition", and the counter intuitiveness of such a statement doesn't depend on the language.

Abigail

I didn't mean that "just in perl" it's counter-intuitive, I meant, the way perl forces you to do it is counter-intuitive. Of course what is intuitive differs depending on the person, I just find it much more natural to put the condition first. I would never say, "I use my umbrella if it rains." I would say, "If it rains, I'll use my umbrella." Of course as the reply stated below, I could wrap the whole thing in parens and use && but that (IMO of course) is still not as intuitive as saying if(COND) do_something(); I've been working with perl now for years and I still pause and scratch my head when I see that in code. I fear I'll never get used to it.

Either way, I didn't mean to say that it was only counter-intuitive in perl.

A common usage is when you don't want the if statement to obscure the readability of the code:

print "DEBUG: foo is $x\n" if $config->{debug};
[download]

is less distracting than:

if ($config->{debug}) { print "foo is $x\n"; }
[download]

The above statement reads more like English. Also, you can have main-path code not be obscured by error-handling logic, similarly enhancing readability, but this time in the reverse kind of way:

reticulate_splines() unless llamas_roaming_in_strawberries()
[download]

In the above example, we usually reticulate the splines (say 90% of the time), but in emergencies, we skip the statement.

If all languages read exactly like C, it would be boring.

For me, the irritating part about reading code with "if" qualifiers at the end is the sense of letdown I get from figuring out the first part of the line only to see that it might not fire because of the "if". However,

do_something()
    if COND;
[download]

buys me both that initial visual cue that the statement is qualified as well as the satisfaction of the simpler, less "noisy", flavor of "if".

Which part is more important? The conditional or the statement? In some cases its one, some cases the other. And if you really want the conditional in front then just write:

($CONDITION) && do_something();
[download]

But usually you are more interested in what might happen than exactly why so that becomes

do_something() unless $exception;
[download]

But sometime the conditional part really aught to go first:

open ... or die ....
[download]



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

// YES                // YES               // NO
if (cond)             if (cond) {          if (cond) {
  task();               task();               task();
else                  } else {             } else
  alternate();          alternate();          alternate();
                      }
[download]

I love Perl's statement modifiers. I'm often going back to a C or C++ project and finding myself typing something like:

double calc_stuff(double x)
{
    return 0 if x < 0;
    ...
}
[download]

if (condition) { task() }
task() if condition;
[download]