4 ms·
It's not the extra 1000 instructions of this call that is concerning. It's the extra 1000 instructions per thing-that-would-have-just-been-a-null-check summed
by mrmekon 13y ago
It's not the extra 1000 instructions of this call that is concerning. It's the extra 1000 instructions per thing-that-would-have-just-been-a-null-check summed over every running process on your machine if this actually took off as a standard idiom.
If we keep adopting readability tricks with orders-of-magnitude differences in speed compared to what we're replacing, we'll just keep getting slower and slower code.
- dragonwriter 13y ago> It's not the extra 1000 instructions of this call that is concerning. It's the extra 1000 instructions per thing-that-would-have-just-been-a-null-check summed over every running process on your machine if this actually took off as a standard idiom. I think for most cases where what you want to do isn't throwing an error on null, most of the time null checks are addressing external interfaces (database or otherwise) where the IO is going to be enough bigger than the pattern overhead that if you are able to deal with the load from the basic functionality, the difference between null check and using this "teller" style implementation is going to be negligible. And, obviously, where you want to error-on-null (whether or not an external interface is involved), this isn't the pattern to apply. > If we keep adopting readability tricks Factoring out commonly used boilerplate into a library function isn't a "readability trick", though it does benefit readability and maintainability of code.
- masklinn 13y ago> it does benefit readability and maintainability of code. And its safety and correctness.