(April 26, 2016 at 9:52 am)KevinM1 Wrote:(April 26, 2016 at 4:56 am)bennyboy Wrote: Saying that a basketball player should develop a good layup right from the start doesn't mean he shouldn't spend a little time trying to see if he can do a slam dunk. Yeah, a visually-pleasing program is a good professional practice. But trying to see how much use you can squeeze into a single line of code, or counting clock cycles on 3 different variants of a routine, can increase programming IQ-- and that can eventually make seemingly impossible tasks possible.
Except it's a PITA to read/figure out in team scenarios where deadlines matter. Hard to read, bleeding edge optimized code should really only be written where the waste of cycles is actually important. Otherwise, you're just wasting development time trying to come up with a new solution to a solved problem, and pissing off your team/boss/client for no good reason.
Basically, do it on the side for your own learning and pull it out of your back pocket if necessary, but don't interfere with development by trying to make good the enemy of perfect.
Or provide a decent comment that explains in plain english what that line of code does.
