You can write it without resorting to one-line conditionals:

  if(cond1){
   myVar = 1;
  }
  else if(cond2 && cond3){
   myVar = 10;
  }
  else if(cond2 && !cond3){
   myVar = 100;
  }
  else {
   myVar = 4;
  }

But when I encounter this kind of situations I have other problems than code formatting anyway:

with 3 conditions you have 2^3 possibilities to check: are you really really sure (!cond1 && !cond2 && cond3) should give you defaultValue ? Do you really want 1 even if !cond2 ? etc...

When possible these conditions should be avoided in the first place (depending on context of course)

If you're running through that many conditionals, it may be clearer to work them into a state enum that you can use with a switch.

Golang doesn't have enums

Neither does JS, but there are ways to accomplish the same thing[0].

[0] https://stackoverflow.com/questions/14426366/what-is-an-idio...

TypeScript does and it’s one of my favorite features.

That's not really the same. That's badly designed and error prone.

That makes code formatting inconsistent because many prefer the other way. The VB.Net style is more compact and readable in my opinion:

        if cond1 then
            myVar = 1
        else if cond2 and cond3 then
            myVar = 10
        else if cond2 and not cond3 then
            myVar = 100
        else
            myVar = 4
        end if

The VB.Net style also makes it easier to identify mismatched blocks because the "enders" are named differently. (One can also put the assignment on the same line as the conditional, but I generally don't recommend it.)

Some may complain it's slightly verbose, but few if any will claim it's not clear.

IMHO, better but it’s still confusing when you have multiple places where you name the variable. Functional programming style forces you to be more explicit and pushes you to separate out the assignment expression. In Elixir I’d do:

    myVar = 
      cond do
       cond1 -> 1
       cond2 && cond3 -> 10
       cond2 && !cond3 -> 100
       true -> 4
      end

ML languages have similar constructs.

Maybe, but that misaligns the values. I'd rather see them lined up. And often more complex logic may be added to the sub-blocks such that the simple pattern goes away. Code should be able to "degenerate well", meaning it shouldn't require lots of rework when the initial pattern fades or changes in the future. It's one of the reasons I often use If/else instead of switch/case statements.

You assigned “myVar” in every branch, right? Let me reread that again to make sure you really are assigning myVar in every case.

That’s a problem. One I’ve seen all too often, but a problem, nonetheless.

As I mention above, it "degenerates" better in that if more code is needed in each sub-block, it's easy to add. I'm okay with syntax that could factor such out if it doesn't require overhauling the block when the starting simple pattern goes away over time. As they say, the wrong abstraction is often worse than no abstraction. Change can kick the simple pattern away.

Alternative solution: put the if/else block in an “IIFE” (which Go supports, just like JavaScript) and change the assignments to returns.

If you are worried with all the cases, you can very easily display your code as a truth table with nearly no overhead in this way:

  myVar =
    (!cond1) && (!cond2) && (!cond3) ? myValue_0 :   // case 0 0 0 blabla 
    (!cond1) && (!cond2) &&  (cond3) ? myValue_1 :   // case 0 0 1 bla
    (!cond1) &&  (cond2) && (!cond3) ? myValue_2 :   // case 0 1 0 blablabla
    (!cond1) &&  (cond2) &&  (cond3) ? myValue_3 :   // case 0 1 1 
     (cond1) && (!cond2) && (!cond3) ? myValue_4 :   // case 1 0 0 
     (cond1) && (!cond2) &&  (cond3) ? myValue_5 :   // case 1 0 1 
     (cond1) &&  (cond2) && (!cond3) ? myValue_6 :   // case 1 1 0 
     (cond1) &&  (cond2) &&  (cond3) ? myValue_7 :   // case 1 1 1 
                                       defaultValue; // uninteresting default (null, -1...)

I think its a poor example. How often you are going to write something like that in RL scenario?

In case of more complex data generation you could use supplier pattern and combine it with strategy.

No need for any if else statements at all.

Sure it requires a lot more of work but is future proof and clear.

I've not heard of the supplier pattern, any chance you would direct me to a resource about it?

A Supplier is when a function needs a value, and instead of providing a value as an argument, you pass in callable:

Foo(int x){return x+1} becomes Foo(Supplier x){return x() + 1}

Function that supplies value, can also encapsulate alot of data generation code. After that you can write a strategy to select which data generation algorithm (supplier) shpuld be used.

Thats my cause.

Thanks.

Im pretty sure you know what i meant, no need for nitpicking.

(Does not make me any less right)

Just maybe he genuinely doesn't know what you mean. I mainly use Python and have no idea what you are talking about.

(You might consider reflecting on your tone and message. It presupposes bad faith on the other party, is dismissive and condescending, and you are probably less right than you think you are.)

I, too, have no idea what a supplier pattern is. Don't think that's a very mainstream notion.

I'm not OP, but I don't know what you mean... Googling it leads me to Supplier in Java 8, which is probably not what you meant?

I can't nitpick what I don't know about. I know the strategy pattern, not the supplier pattern.

It sounds interesting, that was all.

> Combinations of if/else can seriously damage readability and maintainability.

Yes, that's why for selections we usually use switch/case. But of course every programmer worth his money just knows that ?: is right associative and that '&&' is on precedence level 11 while '?:' is on 13. If that's not "clever code", I don't know what is...

> every programmer worth his money just knows that ?: is right associative

I would hope every programmer worth their money are very comfortable with it, because chaining like this is a very common syntactic pattern in other people's code:

  cond1 ? val1 : cond2 ? val2 : cond3 ? val3 : other

It is made less readable if you turn it into a right-nested mess of parentheses, so that is rarely seen.

Just as nobody thinks of 'if..else' as right associative, but it actually is, and everyone uses that fact without thinking about it.

Same for '?:'. The associativity is just a formality that nobody thinks about.

> '&&' is on precedence level 11 while '?:' is on 13

On this I agree. I routinely put parentheses around complex conditions on the left side of ternaries for this reason.

I do remember the precedence, but I think leaving the parentheses out can raise a little doubt in the reader's mind, because it is common to use logical operators for control flow in languages like JavaScript, and control flow is at the same conceptual level as '?:'.

This came up recently on the Swift Evolution forum (which is the official forum for discussing changes to the Swift programming language). Dave Abrahams said, “[…] I keep meeting experienced programmers (really smart people!) that have no trouble reading [a chain of if/else statements] and yet are confused by the analogous ternary construction: [a chain of ?: expressions]”.

https://forums.swift.org/t/pitch-if-else-expressions/22366

My favourite solution to this problem is how rust does it. In rust every block can evaluate to an expression, so if/else is the ternary operator.

    let x =
      if cond1 { expr1 }
      else if cond2 && cond3 { expr2 }
      else { expr3 };

It’s more verbose this way (‘?’ Vs ‘else if’) but there’s no question of readability because it’s just if/else. You can format it however you like, and add statements into the blocks later if you need to, too.

Rust also has the match statement, which is cleaner whenever your conditions are mutually exclusive.

Very lispy :-)

Some would say top-level blocks returning the last value in the block is an anti-pattern, because functions which aren't meant to return a value end up leaking the value of the last thing called in the function, which might be another function, which called another function. Or it might be in various branches of an 'if', which aren't being examined for being an acceptable return value.

Perl does this, (like ECMAScript's 'do'), and while it's usefully concise sometimes, for API-level functions I think it's poor to accidentally leak values to the caller, that should never escape. The safe way to deal with this is an explicit void return at the end of API functions, but that's ugly and hard to remember.

I think JavaScript made the right choice in requiring explicit return from functions with blocks to return a value, with 'undefined' returned if nothing explicit is. Accidents are avoided.

Rust has taken an interesting approach of requiring a return type to be specified, which stops accidental leaks at least. Respect.

Yep! Coffeescript does it too. It was always weird seeing random values pop out of functions while debugging. Also coffeescript's loops evaluate to a list, which meant that functions which ended in a loop in coffeescript would end up constructing and returning arrays that would never be used.

Rust will also only return the last expression in a block if it doesn't end in a semicolon. This can be a bit subtle when you're reading a long function, but combined with explicitly specified return types its hard to mess up while writing code. Because of the choice about that semicolon, its an explicit choice whether you want a block to evaluate into that expression or not. And for functions you can always just use an explicit return statement if you want anyway.

Perl6 has remedied the accidental leak of values to the caller by allowing you to give a return value in the signature.

This will ignore the last result and return Nil instead:

    sub foo ( $_ --> Nil ) {…}

This only works with literals, constants and Nil.

If you specify a type instead, it only enforces that the result is of that type.

> like ecmascript's "do"

Keep in mind this is only a stage 0 proposal, and thus is not really part of the language. This is how statements behave when entered into the repl, e.g. the browser dev console.

(COND ...), anyone? :-)

Ruby has an if/else structure like the Rust/Lisp thing, as well. Tasty.

There's are two pretty simple explanations for that.

1. It's rare, so not many programmers have the pattern matching built up to read it easily.

2. Chained if/else statements have the benefit of indentations helping to show structure. The moment you add newlines to help show structure, a chain of ?:?:?:'s becomes much easier to read.

Most ?: expressions I see are uses inline, such as foo(a ? b : c). When you do that, you sometimes have to mentally unwind "ok so if a... what's a? why a? ok, so if a, then foo(b), else foo(c)". Putting the if(a) up front means you're already thinking about it by the time you get to the function call. So I reserve using ?: for when the difference between the two outcomes is minimal.

>because chaining like this is a very common syntactic pattern in other people's code

If it's very common where you work, then run, don't walk, away...

No, it's very common in code people will encounter if they read a wide range of other people's code outside work.

If you haven't encountered it often enough that it's familiar, than I think you probably don't read much code outside a small bubble.

"readability" is largely a matter of familiarity, so it's very hard to make such sweeping statements accurately. The difference between "common idiom" and "unreadable mess" is "common", not the code itself.

Strongly agree with this. My company has its own coding standards and openly acknowledges that they are not objectively "the right way to do it", because such a thing does not exist. Instead, they define rules to make our code (relatively) safe and consistent.

The Linux kernel has another set of rules that differ in numerous ways (e.g. not wrapping single-line statements under a conditional in braces). Their rules are not strictly better or worse, just different and define their set of common idioms.

Another thing that the MD said to me during my interview was "code ought to be boring, testing can be interesting".

Never thought the ternary operator required high expertise for associativity/precedence reasons and could sentence me to "clever code"...

Besides switch/case do not apply to a mix of true/false conditions but to the different values of a single variable.

Funny :-) Thanks.

> Never thought the ternary operator required high expertise for associativity/precedence reasons

If you chain or nest them.

> Funny :-)

I'm glad I could brighten your day a little bit.

I guess I'm in a minority here, but I wish more non-functional languages would feature pattern matching, of the sort seen in Haskell and OCaml. [0]

This language-design question is essentially a solved problem, but few new languages (outside the pure-ish functional ones) make the effort.

Trivial example in OCaml:

  let imply v = match v with 
       (true,x)  -> x
     | (false,x) -> true;;

[0] https://caml.inria.fr/pub/docs/oreilly-book/html/book-ora016...

It's becoming more popular. Kotlin, Swift and now C# 8.0 have pattern matching (well, close enough at least). I sure hope other languages take note, because you are right about it essentially being a solved problem.

Scala, too.

Yep! Scala's pattern matching is so far ahead of Kotlin's, vis a vis destructuring, that it strains the conscience to say Kotlin has pattern matching at all. FWIW I find both to be enjoyable languages in which to work.

Or break them out into a function, then you can "short-circuit" with a return:

    int logic()
    {
        if (cond1)
        {
            return 1;
        }
        
        if (cond2)
        {
            if (cond3) 
            {
                return 10;
            }
            
            return 100;
        }
        //  ...
        
        return defaultValue;
    }

Since it's a function, it's also apparent that you are only touching one variable:

   myVar = logic();

I love the ternary operator, but I find it's harder to step it in a debugger though.

Short circuiting is poor for readability in my view because not only do you have to parse the syntax but you need to mentally walk through each case to understand what’s going on.

Traditional if/else conditionals express clarity by embedding the decision for myVar and visually show how it would be assigned in various cases.

As @hotBacteria said:

  if(cond1){
   myVar = 1;
  } else if(cond2 && cond3){
   myVar = 10;
  } else if(cond2 && !cond3){
   myVar = 100;
  } else {
   myVar = 4;
  }

  // Now return myVar
  return myVar;

I’ll take this syntax over short circuiting any day.

Clear conditionals like this (or short circuiting) are very nice when it comes to merging.

One liners and mammoth tertiaries that are too long can lead to conflicts and more problematic merges/diffs/etc.

One operation per line makes repos and merging, as well as blaming, reading and reviewing, easier to parse.

I actually prefer the long version. But I think the real trick is to be consistent in style. Parsing ternary operators is a learned skill and so is parsing long if statements. You can get used to both.

Programmers have to learn to read different styles, to read code from other projects. So use the construction that is clearest in its local context.

Style is a matter of taste, just like writing English: there are synonyms and idioms for every idea that you want to express, so use that freedom to choose the clearest communication. Like English, programming code is meant to communicate to other humans, so don't artificially limit your vocabulary in the name of consistency.

Consistency is a hobgoblin.

> Consistency is a hobgoblin.

A foolish consistency is the hobgoblin of little minds.

The whole quote is important. Cutting parts out changes the meaning of the whole thing.

I don’t think consistency is a hobgoblin (I hope I understand the meaning correctly). When you are new to a project you should follow the style of what’s already there and not do something completely different. Obviously there may be good reason but that should be discussed and you also should ask yourself if you are just not willing to adapt or if you are actually making things better.

I have also seen switch statements used (abused?) to do a similar thing. Since a switch executes the first statement that is equivalent to the control expression you can pass true as the control expression, e.g.:

  switch(true) {
    cond1: return 1;
    cond2 && cond3: return 10;
    //etc
  }

Not sure I'd recommend it but it works in a few languages :)

Elixir has cond that does this nicely without resorting to strange switch statements:

https://elixir-lang.org/getting-started/case-cond-and-if.htm...

I prefer to put it into a function and do early return/guard clauses for complex conditionals:

    const pick = (param1, ...) => {
      if (cond1) return 1;
      if (cond2) return 10;
      return 100;
    };

I much prefer the if/else, thanks very much.

I usually write if in such cases.

Or sometimes for multiple condition branches I use bitwise operators to create integer bit mask with couple of bits, then switch(), or array indexer, with all possible 4-8-16 values.

Your version is more error prone because contains more code than necessary. Note how it’s just “else” in original version, and manual negate statement, (cond2) && (!cond3), in your version. Easy to screw up when modifying the code at some later point. When you then need to replace cond3 with cond4, forget about second branch and the algorithm will break.

What we should be able to write in Go, but can't because the compiler (wrongly) imposes formatting:

   if      a       { v =   1 }
   else if b &&  c { v =  10 }
   else if b && !c { v = 100 }
   else            { v = d }

No. This kind of alignment is basically always a mistake and hurts software maintainability in the long run.

The problem is that if one of the conditions changes, for example due to a variable renaming, you likely have to change the alignment on all lines.

Aside from being very tedious even if you're a lone coder, this creates noise in diffs that makes automatic merges fail much more frequently.

I strongly disagree; creative formatting like this means that as a reader, you have to squint and readjust to this new style to see what is going on.

I mean, this whole thread reads like a holy war about code style - something the Go developers EXPLICITLY want to avoid because discussions about code style are a waste of time.

Everyone reading the above segment of code will have a different opinion on how to format it, while the real question should be "What does this code do". I mean this is highlighted in the preface of the presentation: "When you or I say that a foreign codebase is unreadable, what I think what we really mean is, I don’t understand it."

When I read this code I don't understand it, and it's not because of the formatting per se. Playing with the formatting does not make the purpose of the code clearer.

This whole thread where people argue about how to best format a structure is missing the point of the article completely.

> When I read this code I don't understand it

?

Personally when I find myself with these constructs of complicated and nested conditions I try to simplify the branches and condition checking to functions.

This is not always possible, but when it is it's much easier to follow the flow of code and it reduces the number of lines of the condition tree.

  enum situation { boring, clear, cleaver }
  
  selector(context)
    if context.proves(cond1)
      return cleaver
    if context.proves(cond2)
      return clear
    return boring

  adjudicator(context)
    switch( selector(context) )
      cleaver: make_something_cleaver()
      clear: make_something_clear()
      default: make_something_stupid_simple()

Not completely the same situation, though, as there are no assignation here. For simple cases (`v = e0 ? e1 : e2`), ternary operator sure is fine, but for more complex cases, `some_var = selector(context)` tend to be a clearer path. That will also be better rendered in your API as the function fine documentation will have more chance to be extracted properly.

About the only change I would make to your layout is to put a line break after the “?”, with the value sub-indented on the next line, to avoid “guessing” /maintaining how far to tab over the value column.

Thus, it would be layed out like an else-if chain, but without the extra verbiage, particularly the repeated assignment.

(I can’t put in a proper example from my iPad, as it wants to capitalize all the lines, etc)

Disclaimer: Ruby was very influential to me in the mid 2000s, even if I never wrote any for pay. The if (else-if...) statement in Ruby works like a ternary chain in C based languages.

FYI https://news.ycombinator.com/formatdoc

Great info, thanks!

Or

  if(cond1) myVar = 1;
  else if(cond2 && cond3) myVar = 10;
  else if(cond2 && !cond3) myVar = 100;
  else myVar = 4;