in reply to Re^2: Sparing multiple 'or's
in thread Sparing multiple 'or's

I coded for expansion. With the OP's case, I do expect their code to be littered with statements like that. What would you choose? On hash, like I did, with explicit names/keys indicating the purpose of the hash entry (easily expandable) or numerous single-level hashes, all maintained differently.

If it is just for this single statement, it is a fun-to-read thread for all approaches, but none is an actual improvement over the original or'd eqs. I would not change a thing. If this kind of expression will appear all over the code, I'd choose the simplest to maintain method. YMMV.


Enjoy, Have FUN! H.Merijn

Replies are listed 'Best First'.
Re^4: Sparing multiple 'or's
by Eily (Monsignor) on Jun 05, 2018 at 08:55 UTC

    I coded for expansion.
    Yes I understand that. I just thought your solution might be overlooked because it looks more verbose than the other proposals, so I thought I'd show the basic form. Besides, it still works and is expandable if the same test (different variables, same values) can be used in several places.

    What would you choose?
    If there are many sets of data to check against, I would probably choose not to have it directly inside the code, but to import it some way or another. In which case there may be a logical reason (as in the subsets of data are logically link to each other) to gather the data in such a structure, beside being convenient.

    I think not having to repeat the variable is an improvement. It makes it less cumbersome to have an explicit variable name, rather than just $a, and it means less copy/pasting which should be considered a sign that you may not be doing something the right way IMHO.