What does “flatten” mean

If iOS followed the naming convention that you propose, the classes you mention would be named:

• UIObjectResponderViewcontroller

• UIObjectResponderViewcontrollerTable

There would also be classes with names like:

• UIObjectResponderView

• UIObjectResponderViewControl

• UIObjectResponderViewControlButton

• UIObjectResponderViewScroll

• UIObjectResponderViewScrollTable

The disadvantages of this naming convention become more and more apparent as this size of the framework grows:

1. Very long class names.

2. Most classes start with the same long prefix, like "UIObjectResponderView..."

3. The sorted order of source files matches the inheritance hierarchy, which isn't nearly as useful as having them groups according to functionality. That is, it's more useful to have XYDetailView and XYDetailViewController end up close to each other than to have XYObjectResponderViewDetail grouped with all the views, and XYObjectResponderViewcontrollerDetail grouped with all the view controllers.

4. Naming classes according to their inheritance chain violates the "Don't Repeat Yourself" (DRY) principle.

5. Makes name completion almost useless -- you have to type most of a very long name before the list of possible completions is useful. In Cocoa Touch, nearly every class is derived from NSObject, and a great many classes are derived from NSResponder, and the number of views is fairly large. So every time you want to type the name of a view, you'd have to type at least "UIObjectResponderView" just to get to the (long) list of view classes.

6. Doesn't work with prefixes. In Objective-C, name prefixes like "NS", "UI", "CF", and "MK" are used to avoid name collisions. UIKit classes all start with "UI", but all those classes are actually derived from NSObject.

7. Doesn't work well with class names made up of multiple words. A view controller is a controller that manages a view; it is not a view. Using your convention, capitalizing both those words would make "UIObjectResponderViewController" appear to be a subclass of "UIObjectResponderView."

The advantages of more conventional naming schemes are pretty much the inverse of the disadvantages listed above:

1. Allows much shorter names, like "UIButton" instead of "UIObjectResponderViewControlButton."

2. Avoids the tediously long common prefixes. Class names are actually readable: "UITextField," "UISlider", "NSManagedObjectContext" and so on.

3. Source files sort into more useful groups.

4. Doesn't violate DRY.

5. You can type just a few characters of a name and get a useful completion list.

6. & 7. Works fine with different prefixes and with multi-word names.

I'm working in Germany and I prefer to pick English.

Sometimes e.g. domain specific things like creating an module to "DATEV" (german invoice/billing software) I do use German names. Some German words cannot be translated properly, e.g. "Referenzbuchungsnummer" (ReferenceBookingNum?) or "Sachkontenlaenge" (..?). Also I do think that domain specific things would be ending in maintenance horror. Maybe you would remember that ReferenceBookingNum would relate to "Referenzbuchungsnummer", but what about your co-workers? They have to study internal documentation about naming, if documentation exists. They won't be very familiar with the module without having proper names. It's an unnecessary complexity if all other developer are German too. But "CakeFactory" sounds much better than "KeksFabrik" ;)

So it all depends.