Database-bound tests are a drag. Inconsistent tests are a pain. Database-bound, inconsistently failing tests are the worst!
The last post about isEqual: vs isEqualToString: included some timings I made to test the performance of those two calls, along with
compare:. That posting mentioned going down a rabbit hole, verifying commonly held beliefs of about
isEqualToString:. The other rabbit hole I went down related to the performance tuning. A couple of commenters on the post asked some good questions relating to the timings, especially about literal strings.
_TL;DR: When to use
isEqualToString:? There’s no meaningful performance difference between the two. For convenience use
isEqual:. For a modicum of type safety use
isEqualToString:, but it’s not as safe as you might believe. If you have unicode strings with different normalizations, use
compare:. Be careful if
nils are involved.
We have a lot of very convenient, very powerful methods at our disposal such as
[NSData dataWithContentsOfFile:]. This method goes to the file system, opens the file, reads in all the bytes, closes the file, packs the bytes into an
NSData, and returns it back to us. It replaces a loop and several other lines of code into one convenient package. If it can’t do the work, it returns
nil. That’s pretty simple.