[tabtab]

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.

[elcritch]

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.

[tabtab]

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.

[Roboprog]

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.

[tabtab]

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.

[Roboprog]

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