Quote Originally Posted by EntityX View Post
So what's so evil about that?
The source of this program came from a topic entitled "The most amazing VB6 Code ever". I strongly disagree with that assessment.

Yes, the program is pretty amazing, but the code is an impenetrable mess of calculations that does not clearly communicate its intent and is incredibly difficult to comprehend for anyone looking to maintain or extend it.

There are a few places that are simple enough to be understood by themselves. One of those was the Lerp function. The function returned the colour that was partway between two supplied colours (the distance along the line between the two colours being controlled by the k parameter). You've now destroyed that small oasis of clarity not just by making the semantics unclear, but by making the semantics wrong. The 3 multiplier variables are not scoped to the function itself so apply to every linear interpolation. And what does it mean for a LerpkMultiplier1 value of 1.05? It means that (for every linear interpolation performed, remember) that once you have taken the weighted average of the two colours, you will then turn around and add another .05 of the red component of the first colour to the final result.

If you can't see that there's a conceptual problem with that, that would be bad enough. However, you're posting it to the Codebank, thereby promoting it as some kind of good programming practice. That's what's so evil: spreading the idea that sloppy hacking that seems to get what you want is a good way of programming. You've not stopped to consider the fact that you're getting overflow exceptions might imply you've broken some of the fundamental assumptions on which this code hinges? No, you've got a yellow sun and that's what you wanted.


You want a yellow sun? Find the code that determines the base colour of the sun. Don't break the interpolation function to make every colour come out more yellow.