http://qs321.pair.com?node_id=989545

in reply to If statement not working

I don't see any "light pink" color. The code is not efficient, but it is not horrific. Your question appears to be about the logic of the statements rather than the efficiency.

Under normal UI processing, the use of "elsif" would make no practical difference. Please further clarify what you desire.

Update: show some data and explain clearly "why it is not working". Use of "elsif" or hash tables don't seem to go to the point. Please explain why these simple "if" statements are not working for you.

Replies are listed 'Best First'.
Re^2: If statement not working
by andye (Curate) on Aug 24, 2012 at 15:09 UTC
Use of "elsif" or hash tables don't seem to go to the point.

Actually either of those approaches does solve the problem, which is (if I'm understanding the OP correctly) that:

The OP thinks that the 'else' clause will be executed if NONE of the 'if' statements match, whereas actually the 'else' clause will be executed whenever the FINAL 'if' statement fails to match.

i.e. OP's intention was

```if () {} elsif () {} elsif () {} else {}
but OP has got the syntax wrong and actually coded
```if (a) {};
if (b) {};
if (c) {};
if (d) {} else {default()};
where even if one of a, b or c is true then default() is still executed (and overwrites the variable) so long as d is false.

IIU the OP correctly.

I see what you mean, that this is a "dangling else" clause.

I guess something like:

```\$trimmedcolr = \$colr;
\$trimmedcolr = 'BB' if \$colr eq 'baby blue';
\$trimmedcolr = 'BP' if \$colr eq 'baby pink';
\$trimmedcolr = 'DB' if \$colr eq 'dark blue';
\$trimmedcolr = 'DP' if \$colr eq 'dark purple';
\$trimmedcolr = 'HP' if \$colr eq 'hot pink';
\$trimmedcolr = 'LP' if \$colr eq 'light purple';
would have worked although the hash based solutions in this thread are probably more efficient. BTW, I have no problem with this trailing "if" syntax in a situation like this were the intent and readability is very clear.

The "why" question wasn't asked. However since Perl is so good at processing strings, I would suggest that translating an easily understandable string into a shorter more cryptic string is usually just not necessary or advisable.

I would not do this translation without a good reason. One reason might be that this program talks to something else that only understands the two letter abbreviations, however in that case, the default of not abbreviating the color doesn't appear to make sense. Making this a subroutine and returning an error in the case of an unknown color might make sense. I don't know what this "abbreviate it if you can" idea accomplishes.

Update:
Without a good reason, I wouldn't do this, but consider this:

```#!/usr/bin/perl -w
use strict;

my @colors = ( 'baby blue',  'baby pink',
'dark blue',  'dark purple',
'hot pink',   'light purple',
'wild green', 'crazy yellow',
'wild crazy purple', 'deep purple');

foreach (@colors)
{
print getColorAbreviation(\$_),"\n";
}

# The translation algorithm appears to be straight-
# forward, so a table independent translation is
# possible ... Of course 'dark purple' and 'deep purple'
# would translate into the same thing, but maybe that is
# ok? This is application dependent.

sub getColorAbreviation
{
my \$color = shift;  #like: 'wild crazy purple'

\$color = uc \$color;
my @FirstCaps = \$color =~ /(\w)\w+/g;

return @FirstCaps;  #like: WCP
}

__END__
BB
BP
DB
DP
HP
LP
WG
CY
WCP
DP