4 ms·
About 1/3 of the bugs on my current project would have been prevented just by strict null checking alone. I've seen bugs on projects with 100% test coverage tha
by cageface 7y ago
About 1/3 of the bugs on my current project would have been prevented just by strict null checking alone. I've seen bugs on projects with 100% test coverage that would have been caught by types. Dynamic typing was a mistake.
- joelbluminator 7y agoAre you talking about using Optional or things like that in java? That's pretty recent so you can't say that's a property of a static language. And it brings its own problems with it.
- cageface 7y agoWhat problems does it bring with it? It's just a tool that automatically tells you where you need to deal with possible null values. It's far easier than trying to catch every possible place this can happen with loads and loads of manually written tests. Not all static languages give you this but the trend is pretty clear with Typescript, Swift, Kotlin etc.
- joelbluminator 7y agoI can't say the use case for Optional is even well defined https://stackoverflow.com/questions/26327957/should-java-8-getters-return-optional-type/26328555#26328555 https://stackoverflow.com/questions/26327957/should-java-8-g... . I'm no good in java, this is just what I find on the web.
- cageface 7y agoHave you actually worked in a language with good, first-class null handling? I'm not surprised that something tacked onto java very recently is awkward to use but in Swift or Typescript it's much easier than wrapping if foo.nil? calls everywhere and much more effective.
- xzel 7y agoWhat? The use case for an optional type has been been documented for decades and iirc is sourced from type theory. See it’s usage in Haskell (Maybe type) as one aged example. Also, that stack over flow is pretty well clear on what it should be used for imo.