I always thought I suffered from imposter syndrome until I saw what the previous developer on this NodeJS/SailsJS project did.

They put return statements inside of a switch block. He also put in the break statements as well. The return statements were the exact same thing every time it was written.

Fuck shitty JS developers....

I hate seeing it, but I also know that plenty of analysis tools have rules to vomit if switch statements don't have break, regardless of whether or not it's needed. Build systems run by admins will then decline to build the resulting code.

So I try not to judge unless I see something truly shit like O(n) that should be O(1).

Re: this shit
https://rules.sonarsource.com/javas...

@SortOfTested yeah I know what you mean. The switch cases had if-else statements inside of them, with their own return statement, so the break statement was unreachable.

The return statements were setup like the following { data1, data2}. Throughout all the cases and if/else blocks only data1's contents would change data2 stayed the same.

This was just straight trash code and it didn't matter how much perfume was sprayed on it.

@TestInProd423
Imperative code be like^ 🤣

case abc:
assign this to that;
break;

return that;

is hard coded so deep into my ways of doing things that code looks horrible to me without them, plus other languages that literally fall through unless there's a break 🤷‍♂️

But a return in a case.... "exit early" can go fuck it's self.

Wow, that was an easy "fix".
Just find the very tiniest smidge of code style difference (not even actual code smell) in code not written by yourself and *wooosh*, its gone.
Now you only need to find a way to get that newly aquired overconfidence below 9000...

@C0D4 early exit has its places, but it's rarely in a switch