which is better practice

Discussion in 'Perl Misc' started by Ken Sington, Jul 13, 2004.

  1. Ken Sington

    Ken Sington Guest

    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
     
    Ken Sington, Jul 13, 2004
    #1
    1. Advertising

  2. Ken Sington

    Vetle Roeim Guest

    On Tue, 13 Jul 2004 03:49:29 -0400, Ken Sington
    <ken_sington@nospam_abcdefg.com> wrote:

    > 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... ;)


    [...]


    --
    It's not a bug, it's the future.
     
    Vetle Roeim, Jul 13, 2004
    #2
    1. Advertising

  3. Ken Sington

    Anno Siegel Guest

    Ken Sington <ken_sington@nospam_abcdefg.com> wrote in comp.lang.perl.misc:
    > 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
     
    Anno Siegel, Jul 13, 2004
    #3
  4. Ken Sington wrote:

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


    I would go with this as there is no other use for the surrogate $test variable.

    But both are good.
     
    Peter Hickman, Jul 13, 2004
    #4
  5. Ken Sington

    Tore Aursand Guest

    On Tue, 13 Jul 2004 03:49:29 -0400, Ken Sington wrote:
    > 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.


    --
    Tore Aursand <>
    "If your project doesn't work, look for the part that you didn't think
    was important." (Arthur Bloch)
     
    Tore Aursand, Jul 13, 2004
    #5
  6. Tore Aursand wrote:
    > On Tue, 13 Jul 2004 03:49:29 -0400, Ken Sington wrote:
    >> 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.


    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
     
    Jürgen Exner, Jul 13, 2004
    #6
  7. Ken Sington

    Guest

    Ken Sington <ken_sington@nospam_abcdefg.com> wrote:
    > 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

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
     
    , Jul 13, 2004
    #7
  8. Ken Sington

    Keith Keller Guest

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

    On 2004-07-13, Ken Sington <ken_sington@nospam_abcdefg.com> wrote:

    > 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

    - --
    -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-----
     
    Keith Keller, Jul 13, 2004
    #8
  9. In article <>,
    Ken Sington <ken_sington@nospam_abcdefg.com> wrote:

    > 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
     
    Richard Morse, Jul 13, 2004
    #9
  10. Ken Sington

    Ken Sington Guest

    Abigail wrote:
    > 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?
    >
    >
    > Abigail
     
    Ken Sington, Jul 14, 2004
    #10
  11. Ken Sington

    Tore Aursand Guest

    On Wed, 14 Jul 2004 00:09:07 -0400, Ken Sington wrote:
    > ... 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).


    --
    Tore Aursand <>
    "What we do is never understood, but only praised and blamed."
    (Friedrich Nietzsche)
     
    Tore Aursand, Jul 14, 2004
    #11
  12. Ken Sington

    TLOlczyk Guest

    On Tue, 13 Jul 2004 03:49:29 -0400, Ken Sington
    <ken_sington@nospam_abcdefg.com> wrote:

    >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 .
    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.
     
    TLOlczyk, Jul 14, 2004
    #12
  13. Ken Sington

    Tore Aursand Guest

    On Wed, 14 Jul 2004 07:49:50 +0000, Abigail wrote:
    >> 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);


    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. :)


    --
    Tore Aursand <>
    "Be nice to nerds. Chances are you'll end up working for one." (Bill
    Gates)
     
    Tore Aursand, Jul 14, 2004
    #13
  14. Abigail wrote:
    > Tore Aursand () wrote on MMMCMLXX September MCMXCIII in
    > <URL:news:p>:
    > ()
    > () 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
     
    Jürgen Exner, Jul 14, 2004
    #14
  15. Abigail <> writes:
    > 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
    --
    Come to think of it, there are already a million monkeys on a million
    typewriters, and Usenet is NOTHING like Shakespeare.
    -- Blair Houghton.
     
    Eric Schwartz, Jul 15, 2004
    #15
  16. Eric Schwartz <> writes:
    > Abigail <> writes:
    >> while (my ($key, $value) = each %hash) { }

    >
    > 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
    --
    Come to think of it, there are already a million monkeys on a million
    typewriters, and Usenet is NOTHING like Shakespeare.
    -- Blair Houghton.
     
    Eric Schwartz, Jul 15, 2004
    #16
  17. Also sprach Abigail:

    > Eric Schwartz () wrote on MMMCMLXX September MCMXCIII
    > in <URL:news:>:
    > __ Abigail <> 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
    --
    $_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
    pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
    $_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
     
    Tassilo v. Parseval, Jul 15, 2004
    #17
  18. Abigail <> writes:
    > Eric Schwartz () 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
    --
    Come to think of it, there are already a million monkeys on a million
    typewriters, and Usenet is NOTHING like Shakespeare.
    -- Blair Houghton.
     
    Eric Schwartz, Jul 15, 2004
    #18
  19. Ken Sington

    Anno Siegel Guest

    Abigail <> wrote in comp.lang.perl.misc:
    > Eric Schwartz () wrote on MMMCMLXXI September MCMXCIII
    > in <URL:news:>:
    > && Abigail <> writes:
    > && > Eric Schwartz () 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
     
    Anno Siegel, Jul 16, 2004
    #19
  20. Abigail <> wrote:

    > 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

    --
    #!/local/bin/perl5 -wp -*- mode: cperl; coding: iso-8859-1; -*-
    # matlab comment stripper (strips comments from Matlab m-files)
    s/^((?:(?:[])}\w.]'+|[^'%])+|'[^'\n]*(?:''[^'\n]*)*')*).*/$1/x;
     
    Peter J. Acklam, Jul 16, 2004
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dot_net_junky

    Which is better, C# or C++?

    dot_net_junky, Feb 9, 2005, in forum: ASP .Net
    Replies:
    3
    Views:
    462
    Tor Bådshaug
    Feb 14, 2005
  2. Peter Bencsik
    Replies:
    2
    Views:
    880
  3. Suganya
    Replies:
    0
    Views:
    363
    Suganya
    Mar 13, 2008
  4. Andrew Thompson
    Replies:
    8
    Views:
    164
    Premshree Pillai
    Jun 7, 2005
  5. Replies:
    2
    Views:
    70
    Mark H Harris
    May 13, 2014
Loading...

Share This Page