which is better practice

K

Ken Sington

In general, which "if" is better practice?
Or does it depend on what you'd like to do?
Or it doesn't matter; it's a matter of taste?


I think both of these do the same.

=======================================
$test = checkMe($var);
if ($test eq "good") {
#pass
}


=======================================

if (checkMe($var) eq "good") {
#pass
}


=======================================

checkMe() is a pseudo function
 
V

Vetle Roeim

In general, which "if" is better practice?
Or does it depend on what you'd like to do?
Or it doesn't matter; it's a matter of taste?

It's probably a matter of taste.


[...]
=======================================

if (checkMe($var) eq "good") {
#pass
}

I prefer this one, as it's easier to read what the
test is all about.

You know, this isn't really a Perl question... ;)


[...]
 
A

Anno Siegel

Ken Sington said:
In general, which "if" is better practice?
Or does it depend on what you'd like to do?
Or it doesn't matter; it's a matter of taste?


I think both of these do the same.

They do.
=======================================
$test = checkMe($var);
if ($test eq "good") {
#pass
}


=======================================

if (checkMe($var) eq "good") {
#pass
}


=======================================

If you need the result of checkMe() again, use the variable. If you
don't, don't.

Anno
 
T

Tore Aursand

I think both of these do the same.

They do, actually.
$test = checkMe($var);
if ($test eq "good") {
#pass
}

if (checkMe($var) eq "good") {
#pass
}

If you need '$test' later in your script, use the first one. If not,
you're better off with the last suggestion.
 
J

Jürgen Exner

Tore said:
They do, actually.


If you need '$test' later in your script, use the first one. If not,
you're better off with the last suggestion.

Agreed. Plus, if checkMe() isn't a true function but has side effects then
you may not be able to call checkMe() twice without undesirable results.

jue
 
C

ctcgag

Ken Sington said:
In general, which "if" is better practice?
Or does it depend on what you'd like to do?
Or it doesn't matter; it's a matter of taste?

I think both of these do the same.

=======================================
$test = checkMe($var);
if ($test eq "good") {
#pass
}

Ok, now I'm left hanging, thinking "Where is he going to use the value
stuffed into this $test variable again?"

Also, you don't seem to be using strict!
=======================================

if (checkMe($var) eq "good") {
#pass
}

This is tidy, and is a better practise. (Unless, of course, you *are*
going to use $test later on)

Xho
 
K

Keith Keller

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Or does it depend on what you'd like to do?

It looks like the answer is "it depends". :)
if (checkMe($var) eq "good") {
#pass
}

I too do the above, unless I need the value of checkMe($var)
later.

- --keith

- --
(e-mail address removed)-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFA9At5hVcNCxZ5ID8RAtMvAKCb/PMkTMrjS4Q3WV4GJngrnr0AZACfbHvj
coRXuA7DDFcmx2Yx2g8EENM=
=wqZ5
-----END PGP SIGNATURE-----
 
R

Richard Morse

Ken Sington said:
In general, which "if" is better practice? [snip]
$test = checkMe($var);
if ($test eq "good") {
#pass
} vs.
if (checkMe($var) eq "good") {
#pass
}

It depends. Simple is always good, so if you have no need for the
'$test' value except in the if statement, I find the latter easier to
read.

OTOH, if you plan to actually do something with '$test' other than a
mere eq test, the temporary variable saves needing to do the same
computation twice.

HTH,
Ricky
 
K

Ken Sington

Abigail said:
Ken Sington (ken_sington@nospam_abcdefg.com) wrote on MMMCMLXIX September MMMCMLXIX$%@!!@&!!

\\ In general, which "if" is better practice?

Pointless question. If you don't have a measurement what's the point
ok, it must be specific than general.
It seems perl folks have different standards.
Like really short code that fits in a single screen.
of talking about "better"? Better by what standard? Less keystrokes?
Quicker to compile? Quicker to run? Easier to understand? By whom?
.... so like instead of
$x = 1 + 1;
$x = fnct1($x);
$x = hex ($x);

I notice in some perl code:
hex (fnct1(1 + 1));

I think its easier to work with (or upgrade) muliple line format code.

....

- What the phase of the moon is.
what is the phase of the moon in mongolia?
 
T

Tore Aursand

... so like instead of
$x = 1 + 1;
$x = fnct1($x);
$x = hex ($x);

I notice in some perl code:
hex (fnct1(1 + 1));

I think its easier to work with (or upgrade) muliple line format code.

As most of us (if not all) have pointed out: It all depends on the actual
scenario you're facing.

Let's take a look at the code above for a moment. If I would have been
quite sure that $x won't have to be "messed with", I would certainly have
written it on one line;

my $x = hex(fnctl(1 + 1));

On the other hand, if I were certain that $x was the sum or product of
other variables, I would have spread it out;

my $y = 1;
my $z = 1;
my $x = hex(fnctl($y + $z));

So. It all depends. Don't blame the language for letting you choose
between multiple options which all very well could fit your specific
need(s).
 
T

TLOlczyk

In general, which "if" is better practice?
Or does it depend on what you'd like to do?
Or it doesn't matter; it's a matter of taste?


I think both of these do the same.

=======================================
$test = checkMe($var);
if ($test eq "good") {
#pass
}


=======================================

if (checkMe($var) eq "good") {
#pass
}


=======================================

checkMe() is a pseudo function
I'll generally write the second, but at some point
I am going to want to see what checkMe returns,
so I will change it into the first version and add
the print statement. Once I am sure of what's going
on I'll remove the print. Sometimes I'll leave it the
way it is ( especially if I think I might add the print later )
and sometimes return it to the second form.


The reply-to email address is (e-mail address removed).
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,

**
Thaddeus L. Olczyk, PhD

There is a difference between
*thinking* you know something,
and *knowing* you know something.
 
T

Tore Aursand

And that could also have been written as:

my $x = hex fnctl +(my $y = 1) + (my $z = 1);

You're right, of course, but IMO _that_ is bad practice; Declaring
variables inside statements (...) can be confusing (and hard to spot later
on).

However, this is Perl so everyone can do as they wish. :)
 
J

Jürgen Exner

Abigail said:
Tore Aursand ([email protected]) wrote on MMMCMLXX September MCMXCIII in
<URL:()
() On the other hand, if I were certain that $x was the sum or
product of () other variables, I would have spread it out;
()
() my $y = 1;
() my $z = 1;
() my $x = hex(fnctl($y + $z));

And that could also have been written as:

my $x = hex fnctl +(my $y = 1) + (my $z = 1);

While certainly possible I would consider this confusing. In general you
wouldn't expect variable definitions to happen inside of expressions.
When searching for where $y was defined the typical programmer would see $x
= <something>, think "In this line $xz get's defined, not what I am looking
for" and move on the next line.

jue
 
E

Eric Schwartz

Abigail said:
Yet declaring variables inside statement isn't at all uncommon:

For some kinds of statements, yes. For others, not so much.
for (my $i = 0; $i < @array; $i ++) { }
foreach my $elem (@list) { }

Totally unremarkable. I wouldn't even blink.
while (my ($key, $value) = each %hash) { }

A tad unusual, but then I don't tend to operate on hashes that way.
Pretty much unusual.
if (my ($first, $second) = $var =~ /(\w+) (\w+)/) { }

I know this is fine, but I'd never write it that way myself; not
because I don't like it, but because (LIST) = $var =~ /REGEX/ is not
idiomatic for me.
my $x = my $y = 0;

Legal, but why not just do

my ($x, $y) = (0,0); or
my ($x, $y); $x = $y = 0; ?

That second 'my' throws me off; I don't think I've seen it, and it's
not what I would recommend for a coding style. I'm fairly sure I've
never seen it in code I've been asked to review, and definitely not in
any code I've written.
open my $fh => $file or die;

I need to get in the habit of using lexical filehandles.
GetOptions "option=s" => \my $opt;

This is just plain unusual; not illegal or wrong, or any such, but
it's the first time I've ever seen it. I predeclare my options, or
use a hash, mostly for clarity. I certainly would call it uncommon.

-=Eric
 
E

Eric Schwartz

Eric Schwartz said:
A tad unusual, but then I don't tend to operate on hashes that way.
Pretty much unusual.

USUAL. Pretty much USUAL. Geez.

-=Eric, fairly sure someone must have screwed his head on for him today
 
T

Tassilo v. Parseval

Also sprach Abigail:
Eric Schwartz ([email protected]) wrote on MMMCMLXX September MCMXCIII
in <URL:__ Abigail <[email protected]> writes:
__ > my $x = my $y = 0;
__
__ Legal, but why not just do
__
__ my ($x, $y) = (0,0); or

That would be code duplication. Doesn't matter much for '0', but what if
you aren't assigning '0', but a long, or an expensive expression?

In this case maybe

my ($x, $y) = (LONG_EXPENSIVE_EXPRESSION) x 2;

The above is in list context though, so one might need to use scalar()
on the expression if it matters.

Tassilo
 
E

Eric Schwartz

Abigail said:
Eric Schwartz ([email protected]) wrote on MMMCMLXX September MCMXCIII
__ my ($x, $y); $x = $y = 0; ?

That's more typing. I like the ability to initialize in the same
statement as I declare.

I do too, but in general, it's the declaring variables in the middle
of an expression (unless it's a for or while, in which case it feels
semantically to me like it's the beginning) has never felt right to
me.
You need to get out more. ;-)

I won't deny that. :) But I still haven't ever seen it in the wild, as
it were.
Just as I don't see a point in writing:

my $i;
$i = 0;

I don't see the point of writing:

my $opt;
GetOptions "option=s" => \$opt;

If it were only one option, I might be pursuaded, but I've never used
GetOptions without at least four or five options; almost all my
scripts have --help, --verbose, --debug, and --silent. In that case,
my style would have

##############
# GLOBAL OPTIONS
##############
our ($opt_help, $opt_verbose, $opt_debug, $opt_silent);

##############
# Get command-line options
##############
GetOptions("help|h" => \$opt_help,
"verbose|v" => \$opt_verbose,
"debug|d:i" => \$opt_debug, # :i lets me specify debug levels
"silent|s" => \$opt_silent,
# more options here
);

I don't know that I can come up with a reason other than personal
preference for not declaring them together with the function call, but
it seems somehow more cluttered than the alternative. I'm glad,
though, that Perl gives us these *ahem* options.

-=Eric
 
A

Anno Siegel

Abigail said:
Eric Schwartz ([email protected]) wrote on MMMCMLXXI September MCMXCIII
in <URL:&& > Eric Schwartz ([email protected]) wrote on MMMCMLXX September MCMXCIII
&& > __ my ($x, $y); $x = $y = 0; ?
&& >
&& > That's more typing. I like the ability to initialize in the same
&& > statement as I declare.
&&
&& I do too, but in general, it's the declaring variables in the middle
&& of an expression (unless it's a for or while, in which case it feels
&& semantically to me like it's the beginning) has never felt right to
&& me.

There are also a lot of programmers, specially those coming from a
C, Java or Pascal background that don't think it's right to declare
variables in the middle of a block.

I think that if you can make the step from declaring variables at
the beginning of a block to the middle of a block, the step to declaring
them in the middle of an expression isn't that far off.

That's all the more true because finding a variable declaration in
Perl is of much less importance than in C.

With C (or Pascal, or what have you) you don't know what
behavior to expect from a variable before you have seen its declaration.
In Perl, the "type" (scalar, array or hash) of a variable is clear
at the point of usage, only the (often irrelevant) package/lexical
distinction is in the declaration. The game of chasing a variable
declaration (and then chasing the typedef, and then...) isn't played
much in Perl.

One problem with declarations nested in expressions is that adding
a statement modifier to the expression can render the declaration
invalid. That is the one thing that occasionally throws me with
that style.

[snip]

Anno
 
P

Peter J. Acklam

Abigail said:
Just as I don't see a point in writing:

my $i;
$i = 0;

I don't see the point of writing:

my $opt;
GetOptions "option=s" => \$opt;

Of course, but sometimes there is lots of code between "my $opt"
and the call to "GetOptions". I frequently structure my programs
like this

# declare file-scoped variables and package variables
my $opt;

# subroutines
sub foo {
# doing something depending on $opt
}

# the real action begins; start with getting options
GetOptions "options=s" => \$opt;

Peter
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top