Documentation & examples

[iby]

This is awesome – much needed, would love to see this grow. Any chance you could write up "how to" docs with examples? I tried running fus find and not sure what it outputs. Seems like it searches all Carthage dependencies as well. I guess it must also be able to take into account specific target?

[tsabend]

Sorry for the late reply, I haven't looked at this repo for a while.

Glad you like it and thanks for taking an interest. fus find should list all the Swift classes in the given directory that are never actually used in the code. I use cocoapods not carthage, but assuming the carthage dependencies and the source of your app are in different folders, you could just call fus find from within the source directory or specify the path with -p. At least at the moment, I'm just finding all the .swift files by extension and not actually looking through the pbxproj or anything like that, so it is a bit dependent on the file system.

In the readme, it says

fus find             # Find unused swift classes

but obviously it isn't clear. Do you have any suggestions that might clarify the behavior?

Also, this almost certainly has some missing edge cases (for instance: I don't think I added support for the new associatedtype vs. typealias keywords in swift 2.2), so take the results with a grain of salt for now.

[iby]

Thanks! associatedtype depends on typealias when specifying it in a child, so that shouldn't be any different from existing behaviour? Actually… thinking about this – if the alias isn't used it can be considered redundant, in case with associatedtype that check must be made on associatedtype itself, not typealias. So, yep. That would be different.

It gives a few strange results, for example there's class View that gets inherited 10+ times, but fus tells me that it's unused.

One question is that I thought it would rely on compile files list inside build settings, but when running from the source folder it seems that it doesn't use it. To me this is the only true source of information. Thinking out loud:

Based on project settings you can tell exactly what files are used in all builds – then all other files are redundant. This would be good to know – perhaps something was accidentally not included, for test cases that might be especially useful – the build won't fail, but missing tests won't run.

Storyboards may also contain a lot of references to non-standard classes, mine do a lot. They most definitely should be part of the equation.

[tsabend]

What I meant about associatedtype is that I haven't even attempted to support that keyword, which I really should (and will soon), but you are right in that it will need to search for matches in a slightly different way.

I agree about using the project settings as a better standard than just looking at everything in the folder. Initially, I just based my implementation on this gem which also just uses the path. I recently had to mess around with the XCodeProj gem for work, so maybe I will look at refactoring this tool using that.

As for the storyboards, fus is searching the xml for classnames, but it looks like some case must be broken. Same for inheritance.

Most of the implementation is just a bunch of regexs. If there is any way you could write or even outline failing test cases, that would be great.

In the meantime, I will add some comments to finder.rb and swift_class.rb which will hopefully make what's going on more clear.