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.

Falmarri
  • 297
  • 1
  • 7

6 Answers6

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.

Josh K
  • 23,019
  • 10
  • 65
  • 100
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.

Brian R. Bondy
  • 7,067
  • 32
  • 53
  • 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
  • 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 – phuclv Oct 08 '16 at 07: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.

Wonko the Sane
  • 3,172
  • 1
  • 24
  • 24
  • 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
  • Also, my syntax (I will update the answer again) will allow different combinations of conditions that yours doesn't directly support, without doing the same nesting in your elsif. – Wonko the Sane Oct 19 '10 at 20:08
  • Umm, what? I'm talking about in terms of readability. Readability of code should always be first (hence the example in python). Nesting is confusing. Your example isn't really a logical division of code. It's a functional division of code. What if you wanted to add a condition to your if? You'd have to change 2 different blocks. – Falmarri Oct 19 '10 at 20:09
  • 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. – Wonko the Sane Oct 19 '10 at 20:15
  • Mine will what? Have to be changed? Well it will have to be changed if the use case changes. But if you just want to add another condition it will be plugged in just fine with an extra elif. If it REALLY doesn't fit in but is still part of the logic, THEN you can nest in the `else` block – Falmarri Oct 19 '10 at 20:30
  • Please don't be so defensive - I'm merely trying to point out a reason I, personally, don't find it as useful as the syntax I currently use (and have used for more than 15 years). What I am saying is that, yes, I will have to add a condition to my if( ), and *may* have to add a statement to the code inside that if. However, it is likely that you will need to do the same - you will need to add the elsif, and you *may* need to add code in the then block (for the same reason that I needed to in mine). – Wonko the Sane Oct 19 '10 at 20:37
  • I've added a C#-style switch statement to my answer, which may more closely resemble your syntax. In that case, I just add another case statement to my switch (analogous to your elsif) and I'm done. – Wonko the Sane Oct 19 '10 at 20:44
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.

Peter Turner
  • 6,897
  • 1
  • 33
  • 57
  • 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
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.

  • `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 03 '10 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).

supercat
  • 8,335
  • 22
  • 28