11

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.

Improve this question
10
  • how nested can this be? Commented Oct 19, 2010 at 18:34
  • 6
    +1 for thinking outside the box, but I wouldn't vote to actually implement it. See my answer why below. Commented Oct 19, 2010 at 18:53
  • 1
    So 'then' acts like finally in Java? Commented Oct 19, 2010 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 Commented Oct 19, 2010 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. Commented Oct 19, 2010 at 20:05

6 Answers 6

Reset to default
17

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.

Improve this answer
4
  • 2
    I agree -- very difficult to pick up what it means without an explanation such as you gave. Commented Oct 19, 2010 at 19:26
  • Why is requiring an explanation of how something works too much to expect? Commented Oct 19, 2010 at 20:04
  • 5
    Because it makes code harder to read. Commented Oct 20, 2010 at 0:38
  • I'm not really sure that's fair. Every construct in code has to be explained once. Commented Apr 18, 2014 at 14:21
15

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.

Improve this answer
5
  • 2
    Python doesn't have switch/case statements Commented Oct 19, 2010 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. Commented Oct 19, 2010 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. Commented Oct 19, 2010 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. Commented Oct 19, 2010 at 20:57
  • the code in the question is in Python doesn't mean that the question is about Python, because that can be pseudocode as well. If that's only about Python then it should be tagged as such Commented Oct 8, 2016 at 7:34
8

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.

Improve this answer
11
  • 1
    +1 for "tried and true established methodology" - if there's a reasonable solution for a problem, it's usually best to use it :) Commented Oct 19, 2010 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. Commented Oct 19, 2010 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. Commented Oct 19, 2010 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 Commented Oct 19, 2010 at 20:02
  • 1
    As will yours, unless your "then" truly applies to all conditions, which, as you add more and more of them, becomes less and less likely. And personally, coming from a C/C++/C# background, I find nesting quite a bit less confusing than split syntax (i.e. doing something up here in the "if" or maybe an "elsif", and then doing jumping down and doing something else in the "then". I, personally, find the syntax more readable to have all the conditions together. Might not be right, but it is a more established concept in my day-to-day world. Commented Oct 19, 2010 at 20:15
2

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.

Improve this answer
3
  • Well talk to the creators of python, not me =] Commented Oct 19, 2010 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. Commented Oct 19, 2010 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. Commented Oct 19, 2010 at 20:07
0

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.

Improve this answer
1
  • 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. Commented Nov 3, 2010 at 19:25
0

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).

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.