Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I was just thinking of something that would be really cool to have in my if-elif-else controls.


if condition:
    stuff()
elif condition:
    otherstuff()
then:
    stuff_that_applies_to_both()
else:
    stuff_that_doesnt_aply_to_either()

So basically a then will be run when any of the conditions are run EXCEPT the else condition. Do you think this is useful? It's similar to the try-except-else of python.

I think some of you are nitpicking a very preliminary implementation. The then block would be just like the else block in a try-except block in python. The real reason I suggest this is for situations like this.


m = {}
if condition == '1':
    m['condition'] = condition
elif condition2 == '3':
    m['condition2'] = condition2
elif condition3 == 'False':
    m['condition3'] = True
then:
    run_test_that_relies_on_one_of_the_conditions_being_true()

return m

The then block is scoped to the first if just like the else is. So nesting works fine. And if you need to run a method before the if statements, that really has nothing to do with this use case.

share|improve this question

closed as primarily opinion-based by Bart van Ingen Schenau, gnat, GlenH7, Kilian Foth, thorsten müller Jan 12 at 10:09

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

    
how nested can this be? –  aggietech Oct 19 '10 at 18:34
6  
+1 for thinking outside the box, but I wouldn't vote to actually implement it. See my answer why below. –  Wonko the Sane Oct 19 '10 at 18:53
1  
So 'then' acts like finally in Java? –  Alex Feinman Oct 19 '10 at 19:15
1  
I find then to be a bit confusing. Usually then is implied to occur after an if. I mean, you are saying if condition, then stuff() but then proceed to say then stuff that applies to both –  Matt Olenik Oct 19 '10 at 19:27
2  
+1 for an interesting thought exercise, but I agree with the answers filing this under Bad Idea. It's just not intuitive, and I could see this REALLY tripping up some coders. –  BlairHippo Oct 19 '10 at 20:05
show 6 more comments

6 Answers 6

I think it looks horrible. If you want code to run after a variety of conditions then either (a) recheck those conditions or (b) set a variable to indicated success status.

share|improve this answer
2  
I agree -- very difficult to pick up what it means without an explanation such as you gave. –  tcrosley Oct 19 '10 at 19:26
    
Why is requiring an explanation of how something works too much to expect? –  Falmarri Oct 19 '10 at 20:04
5  
Because it makes code harder to read. –  Antsan Oct 20 '10 at 0:38
    
I'm not really sure that's fair. Every construct in code has to be explained once. –  Magus Apr 18 at 14:21
add comment

Generally you can already do this with a switch/case and a switch/case provides more fine tuned control over what you are proposing.

It also doesn't read properly logically. If A else if B then C. Doesn't imply to someone that C will be executed if either A or B evaluate to true.

share|improve this answer
2  
Python doesn't have switch/case statements –  Falmarri Oct 19 '10 at 20:04
2  
I don't think the question was worded directly towards Python only answers, but if that was the intent please tag as Python as well. –  Brian R. Bondy Oct 19 '10 at 20:13
    
Well, it's not directly worded towards python. The example was in python. But if your response to why this isn't needed is "there's switch statements", well python doesn't have those. –  Falmarri Oct 19 '10 at 20:28
1  
@Falmarri: Fair enough, so I guess my answer to that would be that Python would be better to support classic switch statements. –  Brian R. Bondy Oct 19 '10 at 20:57
add comment

Interesting, but seems to me (admittedly somewhat set in my ways) an invitation for readability, logic, and syntax problems.

Edit: Your if-elif is very simple - what if there were 10 elifs? 20? Would all conditions need to be true? What are the chances of that?
Your if-elif is very simple - what if there were 10 elifs? 20? Wouldn't that make this fairly unreadable?

Also, can easily be achieved by tried-and-true established methodology:

if (thisCondition or thatCondition)
{
  if (thisCondition)
     stuff();
  else
     otherstuff();

    stuff_that_applies_to_both();
}
else
{
    stuff_that_doesn't_aply_sic_to_either();
}

What happens if "stuff_that_applies_to_both" needs to happen before the individual steps? Your code doesn't handle this case:

if (thisCondition or thatCondition)
{
  stuff_that_applies_to_both();

  if (thisCondition)
     stuff();
  else
     otherstuff();
}
else
{
    stuff_that_doesn't_aply_sic_to_either();
}

Finally, this syntax allows for greater flexibility with more conditions: if (thisCondition or thatCondition or anotherCondition) { stuff_that_applies_to_all();

  // Any combination of the three conditions using 
  // whichever logical syntax you'd like here
  if (thisCondition and anotherCondition)
     stuff();
  else if (thisCondition or thatCondition)
     stuff_number_2();
  else
     otherstuff();
}
else
{
    stuff_that_doesn't_aply_sic_to_either();
}

I have been using if/else, but could have as easily used a switch statement with a flag:

Boolean conditionApplies = true;

switch (someConditionToCheck)
{
    case thisCondition:
      stuff();
      break;

    case thatCondition:
        otherStuff();
        break;

    default:
        stuff_that_doesnt_aply_sic_to_either();
        conditionApplies = false;
        break;
}

if (conditionApplies)
    stuff_that_applies_to_both();

Note that I didn't actually need the conditionApplies flag - I could have added the "stuff_that_applies_to_both()" function to both the non-default conditions - I just did this so it looks more like the syntax defined above, albeit the "then" rather than the "else".

Therefore, it seems to me to be a very specialized syntax, where a more general syntax fills the bill and more.

+1 for thinking of a possible feature (keep doing that!), but I wouldn't vote to implement it.

share|improve this answer
1  
+1 for "tried and true established methodology" - if there's a reasonable solution for a problem, it's usually best to use it :) –  bedwyr Oct 19 '10 at 19:23
    
what if there were 10 elifs? 20? Would all conditions need to be true? That's not possible. only 1 elif can be true because it stops evaluating more. –  Falmarri Oct 19 '10 at 19:53
    
My mistake - I read it as "and" when you meant "or". However, I stand by my answer - I'll update it from what you pointed out. –  Wonko the Sane Oct 19 '10 at 19:55
    
Do you really think the syntax you posted in here is clearer than what I suggested? Not only are you checking your conditions twice, but non-nesting is always better than nesting –  Falmarri Oct 19 '10 at 20:02
    
"non-nesting is always better than nesting" Why?! It is a logical division of code into more readable blocks. Let me put it this way - would you rather read a book divided into paragraphs or one just broken into a new line for each sentence? –  Wonko the Sane Oct 19 '10 at 20:05
show 6 more comments

I wouldn't mind using something like this myself today. But, to be sure I'd use it about as often as I use repeat until.

Code would at least look better without the superfluous nesting. Although I prefer Else If to elif. I'd replace the Then with Do and the final Else with Otherwise.

share|improve this answer
    
Well talk to the creators of python, not me =] –  Falmarri Oct 19 '10 at 19:59
    
Oh, I thought you were designing a new language. I was just suggesting the name changes to be more precise, leave elif if you want, but that last else seems like it should be distinct from a regular else. –  Peter Turner Oct 19 '10 at 20:03
    
Well it's not necessarily for a new language, but it's not necessarily for python either. Just a new idea for a syntax rule in general. This could be applied to any language with relatively few side effects. –  Falmarri Oct 19 '10 at 20:07
add comment

It seems like a cool idea. However the only problem i imagine is you are more prone to bugs. Like writing an if/else if and calling blah() in then. Writing an extra else if that doesnt want blah, removing blah from then and adding it to your ifs/elseifs. Then when you or another programmer add another statement you may expect blah to be called but not.

Or you can have several ifs, write a blah and forget all ifs but one require this which would break something. Also chances are if you need them to follow every if you'll put it under the if block. Possibly setting a bool in else (NoUpdate=true) and just write a if(!NoUpdate) {} directly under which is clearer and can be set by an if

I am just saying it seems more prone to bugs, not that i dont like the idea. I wouldnt mind seeing it in a language but i cant imagine any situtaion where i would use it if my language does support it.

share|improve this answer
    
Possibly setting a bool in else (NoUpdate=true) and just write a if(!NoUpdate) {} directly under which is clearer and can be set by an if This is EXACTLY what this is supposed to prevent. That's the whole point of an elif statement. Elif isn't necessary either, it can be checked with if statements, but it gets complicated. –  Falmarri Nov 3 '10 at 19:25
add comment

I find your syntax confusing, but I see some value in the concept. Conceptually, when I've considered the issue, what I've found myself wanting is an "unelse", which basically would execute things in the cases where the last else didn't fire. Looking at it from that angle, I would suggest that one could achieve a similar result via:

  do
  {
    if (condition1)
      ... stuff for condition1 only
    else if (condition2)
      ... stuff for condition2 only
    else
    {
      ... stuff for neither condition
      break;
    }
    ... stuff for both conditions
  } while(0); // Continuation point for break

Another option may in some cases be:

  if ( ( condition1 && (action1,1)) ||
       ( condition2 && (action2,1)) ||
       (action_for_neither,0))
    action_for_either;

A bit nasty looking, but in some cases there may not be any good way of expressing the desired sequence of events other than duplicating code or using goto (which might not be so bad, except for the cartoon someone might insert here).

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.