4 ms·
Interestingly I agree w/ a preference for empty semantics over null semantics, but NOT for the reason "avoid NPE". Rather, I think minimizing branching/forking
by wellpast 7y ago
Interestingly I agree w/ a preference for empty semantics over null semantics, but NOT for the reason "avoid NPE". Rather, I think minimizing branching/forking in the code logic is how complexity is reduced.
For this same reason I don't care for NullObject/Maybe/Optional type approaches which simply do not change the branching forking in your code:
if (val == null) { ...logic... }
This branching here ^ is not improved at all by a different syntactical representation:
((Optional) val).ifNull(v -> ...logic...)
You are still branching, so in my opinion you've made no substantial improvement here. (I can already hear the "but, but..."s.
- p2detar 7y agoI'm dealing with an old code base in which methods tend to process exceptions by catching, logging and returning a null. The dev that wrote this code treated exceptions more like a rare-occurring annoyance rather than a signal for error, thus none of the calling methods had null check branching implemented. The amount of NPEs I had to fix in the past year is astounding. Optional to me is a large leap forward. That being said, I also don't like its verbosity and wish for it to be improved somehow.
- wellpast 7y agoAdvocating programming constructs as a kind of ‘policing’ against bad developers doesn’t work for me. It usually ends up at odds with better objectives & heavily taxes conscientious developers, for whom we should really be optimizing things imo.