4 ms·
Do you have some more context for the before/after of the code? I don't see a big win over if (e != null) {...}
by ThePadawan 6y ago
Do you have some more context for the before/after of the code?
I don't see a big win over
if (e != null) {...}
- rafaelvasco 6y agoApproaching natural language, in this case, gets things a bit more readable. I like it. Of course , for this example in particular , doing e?.(...) is better if the block of code is short;
- deleted 6y ago[deleted]
- tonyedgecombe 6y agoIt could be a check for the lack of an interface rather than not null.
- WorldMaker 6y agoThe bigger win I think for the `not` patterns will be anywhere you remove constructions in the form: if (!(e is Class)) {/*...*/} Sometimes the ! gets visually lost in the extra parentheses. The `not` patterns should especially make it cleaner to write certain styles of DeMorgan substitutions (!a && !b to !(a || b) type things) in ways that will be easier to read. Given those big wins, they alone provide a useful context of some consistency of having the `not` operator even for "simple" cases like (e is not null).
- contextfree 6y agoIt's subtly different in that the != version will call an overloaded != operator if one exists and the "is not null" (or the semantically similar but less self-explanatory pre-9.0 "is object") won't.