Is there a reason why I shouldn't just define #define NSFM [NSFileManager defaultManager] instead of writing it out each time?

Question

There is a built-in shortcut NSApp, is there any reason that I shouldn't add one for NSFileManager?

#define NSFM [NSFileManager defaultManager]

I think omitted this will make my code cleaner and I can't see any benefit to keeping it in. (I plan on doing this in all my projects from now on, so it won't be obscure.)

NSFileManager *fm = [NSFileManager defaultManager] 

Answer 1

Why don't you just use a local variable?

NSFileManager *fm = [NSFileManager defaultManager];
// use fm...

or better yet, inject the file manager as a method argument:

- (void)myMethod {
  //using [NSFileManager defaultManager]
}

becomes

- (void)myMethodWithFileManager:(NSFileManager*)fm {
 //usin fm
}

Since the defaultManager is a singleton (effectively a global), it makes testing really hard. Injecting the dependency saves you typing (as you want) within the method and makes it much easier to unit test—you can inject a test double instead of the defaultManager.

Finally, Cocoa and Objective-C generally come down on favoring explicit code over short code. The philosophy is basically that using more verbose names makes the code easier to read (and thus to maintain). This philosophy goes all the way to Objective-C's selector style with interleaved named arguments. Unless you really can't handle the extra typing (and Xcode's code completion won't work for you), stick with the existing names. When in Rome and all that...

Answer 2

I would use a local variable every time because using the defaultManager is not thread safe. If at any point you start using threads in your application you may end up with hard to find bugs and not know why until you run upon this bit of documentation.