Guidelines for the logical lumping of types into a file.

[chrsmys]

What are people's opinions on when we should add a class/struct to an already existing swift file rather than creating a dedicated file for that class/struct? Also, if we do logically lump classes/structs together, what should this file be named?

For Example: If we have a UITableViewController, should the UITableViewCells that the UITableViewController uses be in the same file? What if later on down the road we want to use that UITableViewCell somewhere else?

My initial opinion on this is that each class should be in a dedicated file so that classes are easier to find.

[Grigs-b]

I would say separate file for all classes. Grouping causes way more confusion than it solves, especially when there's no way to apply it consistently

[ianterrell]

I think one file per type is overly restrictive, but I agree that there are no easy rules for when to group things.

Personally I say take a stab at using one file for similar things when it feels good. General guidelines:

1. Code is logically grouped
2. Code contains private types (required)
3. Want to skim this code at once
4. We're under 1kish lines lines

[mikerunnals]

I like how Apple treats UITableView. This file has 3 classes, 2 protocols, 4 enums and an extension. It's ~400 (swift) lines. I would happily find a WT VC of similar length, with a similar num of types.

[rothomp3]

We did already decide that private types should be "namespaced" by being inside the type that uses them, right? If so, then one file per "over-type" makes sense to me.