The reason they do a call to the empty wait() function is to throw off the optimizer. Only if the compiler supports global optimization would it be able to notice that wait() doesn't have any side effect, which means that the for loop doesn't have any side effect and can be removed.

Another common trick to make a sw-only busy-loop more optimizer-surviving is to define the loop variable as volatile.

Both the above options have much better chance to survive the optimizer than just writing:

for (i = a = 0; i < 10000; i++) {
    a += 2*i;
}

At least if the result of variable a doesn't get used somewhere. Some compilers can even notice that the above loop must always give the same result in a, so they can rewrite the above into:

a = <precomputed_value>;

where the value will depend on the data types of a and i.

But back to the earlier discussion.

The operators >> and << are defined as shift operators, not rotate operators. Any compiler who manages to rotate instead of shift are seriously broken. So seriously broken that it really doesn't matter what is "recommended" coding styles.

Note that there are things that are open to implementation with the shift operators - for example how they handle signed numbers, or if the target hardware doesn't keep integers in two-complements form but maybe instead have a sign bit.

If you look at the source code for a multiprecision math library, you might see loops using the shift operator for walking through all bits in a very large integer.

I recommend everyone to spend time reading the C language standard. It does tell what is guaranteed behaviour and what is implementation-specific or maybe undefined.

The next thing is to decide what are "allowed" assumptions when writing a program. Should all programs always assume that we do not know if the target hardware uses two-complmenent format for negative integers? Are we willing to take the cost of writing code that don't rely on this?

Or are we willing to write code under the assumption that the target hardware might possibly store all integers in BCD format, i.e. not binary but consuming 4 bits for every decimal digit? How is that applicable for an embeded program that at the same time has to set specific bits in specific registers in a specific processor to configure or control a specific pin of the processor?

We may not know what happens in the future, but at least as long as we work with binary computers, no computer manufacturer will dare to throw out the support for two-complement integers just because it would break a huge percentage of existing software implemented in most languages. Who would like a processor that has both +0 and -0?

The shift look assumes that the loop variable can hold 2^n states - but that is a very safe assumption for a program that assumes that the loop variable will perfectly map to the 256 combinations possible from the 8 LED you can directly fit to an 8-bit wide port.