[0.25.0] Source Files sorting? #1389

Closed
OliverLetterer opened this Issue Sep 22, 2013 · 6 comments

Comments

Projects
None yet
3 participants

Hey everyone,

I just discovered the new source file sorting in CocoaPods 0.25.0 (by type and not by name anymore). I wanted to ask, with what intention this was introduced and if there is a way to go back to the old sorting because this works against my productivity.

Imaging you have a local pod on which you iterate very quickly which has a large amount of files. A typical workflow for me involves switching between header and implementation of the same class very quickly and often. I usually do that by selecting the file in the left Xcode navigation panel. The assistant editor is not really an option on a MacBook Air and Quick Open is still slower for me because I usually use surrounding source files as well. I'm wondering what everyone else's opinion is on this and if there is a way for me to increase productivity which I am not seeing right now.

Owner

alloy commented Sep 22, 2013

@irrationalfab Can you respond to this? The last code I saw sorts by name, so not sure what’s going on here.

Owner

fabiopelosin commented Sep 23, 2013

Prior to CocoaPods 0.25 source files where sorted according to the order in which they where are added. However this strategy is not sustainable anymore in the branch which is supposed to introduce the feature to edit the pods project in place as changes might be incremental. Moreover the whole project should be sorted to ensure a more consistent output. For this reason now CocoaPods sorts the Pods project before serializing it.

Originally I implemented the serialization by name there where some complications with files references including characters like + and - in their name which ended up with undefined order and changing place after every call of pod install. As I saw little incentive to further investigate the issue I switched to sorting by type.

I think that sorting by type is more cleaner also for the workflow of @OliverLetterer because you see the name of a class only once in the list of file references (instead of twice header + implementation). To switch between the header and the implementation of a class Xcode offers a convenient shortcut: Ctrl+Cmd+Up or Down.

Not sure if there are any other disadvantages of using this approach. I have to admit that I didn't think about the very common user case of Development Pods when I introduced the change, hence I considered it so minor that I didn't properly documented it as I should have.

Im all in favor of ordering source files properly and i can see where you are coming from. i didnt know about the shortcut for switching between header and implementation, thanks. but im still against ordering by type because:

  • if you add new source files to your apps target, these are grouped by name by default and I and no one i know or worked with so far are using source file sorting by type. Now I and my colleagues might be a minority but this introduces an inconvenience for us. I would love to here some other opinions on that.
  • on larger pod projects, there might already be an implicit ordering due to similar naming conventions and class prefixes (a UITableViewController subclass and some specific UITableViewCell subclasses being named with the same long prefix, eg SLOrdersViewController and SLOrderTableViewCell). Suddenly, you decide to make a private method in the tableViewCells subclass public while working in the viewController. To quickly change to the header file, i previously clicked on it in the left navigation pane (one step). Now, i would have to select the implementation file and open the header file with the shortcut (two steps). This may be one edge case but i believe that there are more cases where productivity goes down due to the new ordering.
Owner

fabiopelosin commented Sep 23, 2013

if you add new source files to your apps target, these are grouped by name by default

Thats a very good point for sorting by name.

Regarding the rest of the points I consider them user preference as sorting by type has also its strengths, so I don't consider them a strong case for sorting by name unless there is some evidence that the described workflows are considered best practices.

Given that we try to match Xcode behavior when in doubt, currently I'm of the opinion that we should switch to sorting by name.

Owner

alloy commented Sep 23, 2013

I think to prevent the undefined order issue you mentioned, we should sort by name, then type, i.e. sort_by { |x| [x.display_name, x.type] }. I believe this should fix those edge cases well enough.

Owner

fabiopelosin commented Sep 23, 2013

Interesting I wasn't aware that you could return an array from sort_by! The solution sounds good to me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment