Re: Sparing multiple 'or's

[Tux]

Personally, I'd use a hash:

my %expr = (
    EX_CASE1 => { map { $_ => 1 } qw( ABA SCO ACC PHC GHF ) },
    EX_CASE2 => {}, # …
    );
:
:
if (exists $expr{EX_CASE1}{$a}) {
    ...
    }
:
if (exists $expr{EX_CASE2}{$b}) {
    ...
    }

but I'd choose more expressive names than EX_CASE1 etc :)

You can also use List::Util's any, but that might read fine, but is very hard to optimize, so it will probably be slower the your current code

use List::Util qw( any );

if (any { $a eq $_ } qw( ABA SCO ACC PHC GHF )) {
    ....
    }

[Eily]

++ For the hash method, although your nested structure makes it look more complex than the other solutions. It can be made to look much simpler using a single level, and the fact that there won't be autovivification in boolean context:

# equivalent to %is_valid = (ABA => 1, SCO => 1, ACC => 1...);
my %is_valid = map { $_ => 1 } qw( ABA SCO ACC PHC GHF ); 

if ($is_valid{$variable}) # Easy to read
{
  ...
}

[Tux]

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.

[Eily]

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.