perl style: can I combine two steps into one?

[Rasto Levrinc]

Rasto Levrinc wrote:




And more likely to move on silently. IMNSHO this is wrong.




Think again about it, and forgot what someone told to you 10 years ago.
IMNSHO programming to work around mistakes in your code is wrong.

Also, it confuses people. Do you:

a = 10
:
: some code that doesn't do anything with a
:
if ( a != 10 ) a = 10 just in case

I hope not.

No I don't. But I still think that program, that goes sometimes, maybe
once a year, silently in the endless loop is a little bit worse, than
program that moves on silently with maybe wrong data. You wouldn't like
endless loop in your kernel for example.
It's not that you want to work around your mistakes, there can be many
reasons, why i skips 10.

 

[John Bokma]

Rasto Levrinc wrote:

[ snip defensive programming ]

No I don't. But I still think that program, that goes sometimes, maybe
once a year, silently in the endless loop is a little bit worse, than
program that moves on silently with maybe wrong data. You wouldn't like
endless loop in your kernel for example.

Ah, but moving on with the wrong data is ok? Both are equally wrong to me.

It's not that you want to work around your mistakes, there can be many
reasons, why i skips 10.

In my example I explicitly stated that i can not do such a thing. If it
can, then it would be an error not to test >=.

But, again IMNSHO, don't try to "fix" things. Code is documentation too, if
I see

i >= 10

I wonder in what cases I can be > 10.

 

[Rasto Levrinc]

Rasto Levrinc wrote:

[ snip defensive programming ]

No I don't. But I still think that program, that goes sometimes, maybe
once a year, silently in the endless loop is a little bit worse, than
program that moves on silently with maybe wrong data. You wouldn't like
endless loop in your kernel for example.

Ah, but moving on with the wrong data is ok? Both are equally wrong to me.

No it isn't ok, it is also wrong, but slightly less dangerous, than to
get in an endless loop. Endless loop is always bad. Wrong data sometimes
are important sometimes not, so statistically they are less evil.

In my example I explicitly stated that i can not do such a thing. If it
can, then it would be an error not to test >=.

If you have a little more complex algorithm, you usually don't prove its
correctness, so you can't say, that you can not do such a thing.
Even if you are 100% sure, that you don't have any mistake in your
algorithm, it is still possible, that something can go wrong outside
your program. For example compiler can have a bug, or faulty hardware
can cause i to skip 10. To test >= is slightly more fault tolerant, than
== in this case, with very little effort.

 

[Anno Siegel]

Anno Siegel wrote:

I lump together closing brackets of all kind, unless I want one to
stand out. You don't want to miss an opening bracket, but the closing

[...]

Ok, so the first line should have be:

sort { $b->[ 1] <=> $a->[ 1]}

?

No, some constructs are special. Closing "}" of blocks, and closing
')' of loop- and if-conditionals do get a preceding blank. Those deserve
to stand out.

Anno

 

[Henrik]

John Bokma skrev:

Another good(?) reason, which also applies to C-code, is that
accidental omision of one + is caught at commpile time, but only if you
use post incrementation.

 

[RedGrittyBrick]

Rasto Levrinc wrote:




And more likely to move on silently. IMNSHO this is wrong.

Since I was raised on FORTRAN, it is deeply ingrained in me that one
should never test floating point numbers for equality. So I tend to feel
more comfortable writing "x >= 10" than "x = 10" where x is being
incremented in some fashion. Unfortunately this aversion also applies
inappropriately to integer comparisons.

Perhaps one should write
last if i == 10;
die "Too many impossible things before breakfast." if i > 10;

;-)

#!perl
use strict;
use warnings;
my $x = 0.0001;
foreach (qw(tum te tum te tum ti tum foo bar baz qux etc)) {
$x++;
last if $x == 10;
}
print "x=",$x;

 

[Anno Siegel]

A programmer shouldn't be bothered by that in normal cases.

If "normal case" includes use of the return value of $x++, it can't
be ignored.

Anno

 

[John Bokma]

John Bokma wrote:

[ snip ]

Since I was raised on FORTRAN, it is deeply ingrained in me that one
should never test floating point numbers for equality. So I tend to feel
more comfortable writing "x >= 10" than "x = 10" where x is being
incremented in some fashion.

It wasn't a float.

Unfortunately this aversion also applies
inappropriately to integer comparisons.

Perhaps one should write
last if i == 10;
die "Too many impossible things before breakfast." if i > 10;

As silly as:

die "Panic" if int( i ) != i;

if i is already int.

If i "suddenly" becomes float, it's quite weird to rely on the fact that
you already took care of i possible becoming float.

 

[John Bokma]

If "normal case" includes use of the return value of $x++, it can't
be ignored.

It was clear I was talking of cases in which the increment is in void
context.

It's obvious that

if ( $i++ ... )

is not the same as

if ( ++$i ... )

( or at least to me ).

Also, in (void context), I can't see why

++$i;

and

$i++;

can not be optimised to be equal. And "Programming Perl" seems to
confirm that:

" The optimizer will notice this and optimize the post-increment into
a pre-increment, because that's a bit faster to execute. " (footnote,
p26 of 3rd edition)

Using constructions because they "feel faster" is odd.

 

[Anno Siegel]

[should $x++ or ++$x be preferred?]

It was clear I was talking of cases in which the increment is in void
context.

Are you saying different rules of preference should apply depending on
context? I hope not. But then all applications must be considered.

Also, in (void context)...

[$i++ and ++$i are optimized to be the same]

Using constructions because they "feel faster" is odd.

I never said anything about speed, I was careful not to.

"++ $x" is conceptually simpler than "$x ++", that's why it should be
preferred. The specific action of "$x ++" is rarely needed in Perl
(though it can come in handy), because the indexing operations it applies
to are usually done by the interpreter. It should be the exception,
not the rule.

Anno

 

[John Bokma]

comp.lang.perl.misc:

[should $x++ or ++$x be preferred?]

It was clear I was talking of cases in which the increment is in void
context.

Are you saying different rules of preference should apply depending on
context?

Yup, I use a hammer when I need one. And when a tweezer is better, I use
that. Sounds to me sound tool usage.

I hope not. But then all applications must be considered.

Also, in (void context)...

[$i++ and ++$i are optimized to be the same]

Using constructions because they "feel faster" is odd.

I never said anything about speed, I was careful not to.

"Pre-increment is the simpler process, not only implementationally.
There are two values involved in $x++, but only one in ++$x. "

Since $x++ is in void context optimized to ++$x there is no difference.
So just using ++$x because you try to think at low level is bad IMNSHO.
Even more since in void context it doesn't matter at all.

"++ $x" is conceptually simpler than "$x ++", that's why it should be
preferred.

Programming Perl 3rd edition just told me that $x++ is optimized into
++$x in void context.

The specific action of "$x ++" is rarely needed in Perl

$hash{ $x }++; ?

A quick find in files using Textpad in my Perl installation over all pm
files gave:

1345 occurences of ++
A quick glance gave me the impression that ++$i is used more than $i++.

Also note that I prefer $i++ in void context. When the value of $i is
directly used it depends on the *context*.

Sometimes:

if ( ++$i == 10 ) ...

is better (to me) compared to

if ( $i++ == 10 ) ...

I use what is best overall, not because of some idea.

 

[John Bokma]

And the subroutine returns a floating point number which, due to
rounding errors, isn't quite an integer.

That's why I prefer to use '$i >= 10' instead of '$i == 10'.

What if the subroutine returns "meh" ?

 

[Anno Siegel]

Anno Siegel wrote:
John Bokma <[email protected]> wrote in

comp.lang.perl.misc:

[should $x++ or ++$x be preferred?]

I have said what I wanted to say about this (more than that, I'm afraid).
This is getting repetitive, we're boring everyone else to tears. Sorry...

Anno

 

[John Bokma]

comp.lang.perl.misc:
Anno Siegel wrote:

[should $x++ or ++$x be preferred?]

I have said what I wanted to say about this (more than that, I'm
afraid). This is getting repetitive, we're boring everyone else to
tears. Sorry...

I can't speak for everyone else.

And programming style is never boring to me :-D. I have given your style
some serious thought, ie. if it doesn't matter to use either $i++ or ++$i
to use ++$i. But since in my experience $i++ is more used in void context,
I stick with the latter. Also since PP 3rd edition states that in void
context it doesn't matter.

 

[Charlton Wilbur]

"DF" == David Formosa (aka ? the Platypus)
DF> Likewise, and like you I've had Lisp esposure.

I do that in LISP. I don't do it anywhere else, because I find that
in languages like Perl and C the vertical organization of code and the
lines of mostly-whitespace that happen when you have braces on a line
by themselves really do help me follow what's going on; and the angled
nested closing braces, each one on its own line, are also helpful.

I'm working now for a company doing some PHP work, and the combination
of optional braces and the K&R/Java-like parsimony of vertical spacing
in their house style means I've been *extremely* grateful for Emacs's
brace-matching.

Charlton