PSA: Writing to leds[NUM_LEDS] can be bad for your health.
Scenario 1: You write a standalone animation and it works like a charm.
Scenario 2: Someone else integrates your animation and it crashes due to that animation writing to leds[NUM_LEDS].
A prime example is:
int posn = beatsin16(13, 0, NUM_LEDS);
leds[posn] = CRGB::white;
At some point the value of posn will be NUM_LEDS and it will write to one LED beyond the end. It may break your code and it may not. It will probably break the code of the programmer who re-uses it in another fashion.
Indeed! Writing to pixels that don’t exist may cause bad things to happen. When you least expect it. Your milage may vary. No guarantees. Warranty void.
As a side note, I found that using the leds[] array directly to iterate an animation is detrimental in the long run. I think it’s better to design animations to use their own variable arrays to store states, and then “paint” them into leds[]. It takes more memory and bit more clock cycles, but it’s nothing recent CPUs can’t handle. When your animation library grows and gets more complex, it gives you more control and makes overlaying possible and easier.
I usually go with declaring END_LED as NUM_LEDS-1 then iterating from 0 to END_LED, where necessary, which makes things a bit more readable (for me at least)