Wednesday November 30, 2011

So, What's A Good Practice With Groups And Directories In Xcode?

I asked the legendary Wil Shipley of Delicious Monster for his thoughts on whether to try to keep directories organized on the file system or just throw everything in the same place and use groups in Xcode. Here’s his advice:

I just use groups unless there’s an actual second or third target – separate targets get their own subdirs.

Xcode doesn’t care about where your source files are. If you rearrange files in the sidebar or put them in to groups, they aren’t moved around on the filesystem, even if your groups refer directly to directories. I think I understand the logic behind this. With Objective-C’s heritage, directory structure isn’t that important for organization. Conventionally, each file has a unique name based on the class name. Since there is no namespacing in Objective-C, it’s all done with prefixes.

When I first came to Objective-C, I was meticulously grouping my source files in subdirectories and in Xcode groups. If I needed to move things around during a refactor or rewrite I had to move the file and then move the reference in the Xcode sidebar. Too much friction to evolve the organization of a code base, in my opinion.

So, recently I’ve been just letting Xcode handle all the grouping and organization for me and leaving my source files in a single directory. It works. And it’s good to hear that it’s a common practice, according to Wil. If I drop down to work in vim it isn’t a problem since I use a fuzzy file finder, anyway. It’s not ideal since I think we’re ignoring the file system as a very valid way of organization, but for the time being going with the flow lowers the friction for what is more important.