For example, ReSharper is showing up a number of places in which QB64 has switch statements with individual cases ended with return and break, the latter will never be triggered since return will always execute. Maybe there is a reason for this redundancy I'm not familiar with (as noted, I'm a C++ n00b).
Uhh, in this case you should better drop ReSharper immediately. A code optimizer, which suggests removing a break from a switch case, just because it is never reached during runtime yet, is a BAD tool.
One basic rule in C/C++ when doing switch blocks is: "Always have a break in EVERY case." First it prevents the
program from falling through from one to another case, if your code is not running as expected during development, second when you add more cases it's obvious where to add them (after the break) to not accidently destroy the flow of an existing case by adding the new case in the middle of another case.
EDIT:
And third, think about it. You remove the break now, as it's never reached because of the return before it, good.
If it happens in the future, that we need to replace the return with some other code (let it be a bugfix or a new feature), would you remember to add a break then again?? - Because then it is needed, cause the return is no more.
