in reply to Re: Complex conditional statements
in thread Complex conditional statements

Sorry, should've made myself more clear...

ikegami has correctly decrypted the logic of that statement a few posts higher. However, it is just a test piece...

What i'm trying to accomplish is: i have a script that is supposed to transfer files from ftp to certain directories (on WinNT/XP platform). The script has been failing randomly when downloading the files, with the error message saying "Bad file descriptor", which can mean almost anything. The files are there every time the transfer occurs, whether success or failure.

I'm trying to introduce a --test option to the script, that would do a "dry run", without actually transferring the file, just printing status messages on every step. Since the majority of the code is the same for test and normal run, I want to use those if, and, or, unless keywords, and I want to keep the code compact. I have a C background, so my code did look like a C program... well, initially it did. But I'm realy impressed with the power of Perl to mangle several statements together like this, and trying to use that.

If there are better ways to do this, I'm open to suggestions...

--------------------------------
An idea is not responsible for the people who believe in it...

Replies are listed 'Best First'.
Re^3: Complex conditional statements
by mrpeabody (Friar) on Jun 16, 2005 at 17:17 UTC
    I'm trying to introduce a --test option to the script, that would do a "dry run", without actually transferring the file, just printing status messages on every step. Since the majority of the code is the same for test and normal run, I want to use those if, and, or, unless keywords, and I want to keep the code compact. I have a C background, so my code did look like a C program... well, initially it did. But I'm realy impressed with the power of Perl to mangle several statements together like this, and trying to use that.
    Now the problem is clear. You have a simple requirement that can be expressed clearly in code. However, giddy with the newly-discovered expressive power of Perl, you're looking for a way to squeeze what you want to say into as small a space as possible.

    Don't. It makes code ugly, complicated, and damned near impossible to understand, never mind maintain. It makes people hate Perl programmers and hate Perl. It's a fun game, and can even teach you something about the language, but you should never do it on production code (defined as code you will run more than once).

    In addition to which, the specific trick you're trying to use is not allowed. Statement modifiers are limited to one per statement.

    If there are better ways to do this, I'm open to suggestions...
    ikegami has the right idea:
    if ($comment or $test) { $a = 3; print "--> $a\n"; } else { print "no way!\n"; }
    By the way, where can I find references to the syntax of those Perl keywords? I tried to search for them, but they aren't functions, and Google promptly omits them from the search criteria...
    They are documented in perlsyn.
Re^3: Complex conditional statements
by Tanktalus (Canon) on Jun 16, 2005 at 16:44 UTC

    To be honest, I think the better way to do it really is to not use those keywords (at least, not as statement modifiers), and not to keep the code compact. Whitespace is your friend. Especially after six months.

    I don't know if you noticed it, but most of the people who have given analysis of your "complex conditional statement" (to use the term you used in the subject line) have added newlines and other whitespace just so they could wrap their heads around what was going on, and to help explain the logic that they were assuming you meant. This is a good indicator that your code, if you want it easy to read, decipher, and analyse later, should do similarly: add newlines and whitespace. Exactly the opposite of compact.

    As long as you're spreading it out a bit, you probably should also use the if/unless keywords in their non-modifier form. This just makes things so much easier to understand. Remember - we're not writing code for the computer, but for the human reader. ;-)