--- In [email protected], "mikejd42" <mikej...@...> wrote: > > newpixel = ( pixel1 + pixel2 ) >> 1; > > This is hard to understand?
Harder than: newpixel = (pixel1 + pixel2) / 2; because I (and I think others) would think - why are we using a bit shift here? Are the pixels bit masks or something? Now it doesn't take long to understand in this context, but I'm talking about a principle here - don't make things any more complicated than they already are without good reason. > Maybe because I come from a electronics background but the above code is very > easy to understand! Very easy to debug! and has worked flawlessly for over 30 > years. You're talking about a single line of code. If only all programs were like that :-) > > And far too many programmers attempt to optimize their code and end up with > > a mess, instead of concentrating on a good, clear design. If there are > > still performance problems, then by all means look for areas to optimize > > (probably after running some sort of profiler). > > Here again this is good clean design, fast and efficient. This is not "an > attempt to optimize code" But I think that's how you described it in your original post "faster with less overhead.". > it is a good habit Disagree! > that has valid roots going back many years. Doesn't make it good :-)
