Swift comes with a number of features that help developers write correct bug-free programs: optionals, safe casting, and built-in error handling. B...
For further actions, you may consider blocking this person and/or reporting abuse
The points made in this post are very real. What we did to enforce these rules was to use SwiftLint so that people were forced to refactor their code and not use any force unwrapping, otherwise the build process would fail. If the developer was %100 sure that using force unwrapping was the only way to write that piece of code, then they could ignore the error with a specific SwiftLint comment, and we would decide whether it was absolutely necessary to use force unwrapping or not, during code review.
That's a great combination of several different techniques! Adding review layers where somebody needs to justify their use of an unsafe language function adds that mindfulness. And Lint+code review generalizes nicely to catch this general kind of code smell.
I really agreed with all the statement about the using of unwrapping optionals. but sometimes on the development it's a necessary evil, if the developer is pretty confident to justify the use of
!in an object and make sure when trying accessing the object value there will be no problem with it, I've seen a lot of usage of the!but is not a practice I really support for me even I prefer to deal with the boiler plate or make something that deals with that using the minimal code required for that operation than deal with bugs.Yes, I love the conversation this has inspired about what others have done to use
!as safely as you can when it is necessary. A strong bias against it is a good default, and being very mindful when you do need to use it (with supporting documentation!).Thanks for this, as someone newer to Swift, I knew this, but now I feel like I really know this. I have definitely snuck in some
!already. 😳I'll admit, it's easy in a weak moment to drop a
!and run away. 😅 I think that's one of the main problems; they made it too easy to do just that, without thinking.Escape hatches are such a funny element of computer programming in general. So terrible yet fairly awesome in some senses. All in all it’s “better” that you “can” ship a quick and dirty solution, but you just shouldn’t do it.
Yeah, re: the discussion with Theodore below, IB outlets are one place where the escape hatch is useful, because the contract that this value will be set when you use it is being fulfilled another way. It probably shouldn't be an absolute 100% never do it, but training a strong bias against it is wise. And maybe some additional guardrails and mindfulness for when you do need to use it (code comments asserting why you believe it's safe, for example).
Outlets are an interesting case. I can mostly get behind those (I'm at about 95% 😁), because even though it is implicitly unwrapped, you are relying on the platform to populate the outlet, and so there is a guarantee of sorts. You could even do static analysis on the code and know that an IBOutlet would be populated before you would ever use it if you wanted stricter enforcement. It isn't perfect, but it's probably the safest place it could be used.
I think it's a healthy stance to strongly bias towards not force unwrapping in general, though. The minute I need to deeply reason about the interactions in the code is where it gets dangerous, and it is much safer if the assurance is enforced in the code, rather than a promise that exists outside of code. I don't want that IOU to be bad debt when I come to collect! 💸