Post History

It's an unfortunate analogy. Apart from being confusing, it does indeed assume some basic electronics knowledge. In electronics a _short circuit_ (or the common jargon "a short") does not necessarily refer to a catastrophic event like cables burning up - it just means that you connect two signals/conductors with no resistance between them.

Whoever decided to use this term in the strange context of programming probably had something like this schematic in mind:

![short_circuit](https://software.codidact.com/uploads/zc7d2udluvs8tpnnyw915ryf19vy)

As we may recall from school, in case we have two resistors in parallel then the current flowing through the circuit is split between them. But in the above picture we have a conductor to the left bypassing R1 entirely. All the current flows through that conductor and zero current flows through R1. We may say that R1 is "short circuited" since both sides are connected to the same conductor.

This means that no matter what circuit or value we put in R1's place, zero current will pass through it. The analogy in programming that in case we have `1 && b++`, then it doesn't matter what we write as the right operand because the program flow will only "pass" the left operand. 

So supposedly we should compare the program counter in software with an electrical current. It is not really a helpful term at all even if you do know basic electronics.

As it turns out, it is probably better to use the formal programming terms. In the C language (and many others), this is referred to as ___order of evaluation___. What that means in detail was explained here: [What is the difference between operator precedence and order of evaluation?](https://software.codidact.com/posts/278172) 

Certain operators like the `&&` and `||` in C guarantee a left-to-right evaluation and also that the evaluation stops if it finds that the result cannot be true. `a && b++` is therefore 100% equivalent to this:

```c
if(a)
{
  if(b++)
  {
    do_stuff();
  }
}
```

The inner `if` will never get executed unless the outer `if` evaluates to true. Similarly, `a || b++` is 100% equivalent to

```c
if(a)
{
  do_stuff();
}
else if(b++)
{
  do_stuff();
}
```


But how can we know if a certain operator "short circuits"? Well if we have programming learning material of dubious quality, speaking of electrical terms, we can always abandon it and just peek directly into the C standard. C17 6.5.13 emphasis mine:

> **Logical AND operator**  
> /--/  
> Unlike the bitwise binary `&` operator, **the `&&` operator guarantees left-to-right evaluation**; if the second operand is evaluated, there is a sequence point between the evaluations of the first and second operands. **If the first operand compares equal to 0, the second operand is not evaluated.**

These two bold sentences are what actually guarantees the "short circuit"-like behavior. 

Most operators in C do _not_ come with such a guarantee. But in higher level languages like Java, operators usually come with more guarantees by the standard and less ambiguous behavior, making Java safer and less bug-prone. The reason why C does not do that at the same extent is because C prioritizes performance over safety. An unspecified order of evaluation gives the compiler more freedom to optimize code. 

We may note the above examples with `&&` and `||` being equivalent to `if` statements. That also means that these operators may boil down to branches during optimization, and branches hurt program performance. The less rules laid out about operator behavior, the easier it becomes to optimize away branches. Boolean logic tends to generate branches, whereas pure arithmetic might not.