Let me give you an example of how I name my classes alphabetically:

  • Car
  • CarHonda (subclass of Car)
  • CarHondaAccord (subclass of CarHonda)

There are two reasons why I put the type of the class earlier in its name:

  1. When browsing your files alphabetically in a file explorer, related items appear grouped together and parent classes appear above child classes.
  2. I can progressively refine auto-complete in my IDE. First I type the major type, then the secondary type, and so on without having to memorize what exactly I named the last part of the thing.

My question is why do I hardly see any other programmers do this? They usually name things in reverse or some random order. Take the iOS SDK for example:

What are the disadvantages of my naming convention and the advantages of their convention?

  • Would you have classes called List, ListLinked, and so on?
    – Philip
    Commented Apr 8, 2012 at 0:31
  • It's a good idea.
    – alan2here
    Commented Apr 8, 2012 at 0:46
  • whats is UX? (Could you provide link please? -- Didn't know about this one). Commented Apr 8, 2012 at 2:30
  • @Jae - Why would it be on UX? This is a programming question about designing class names. UIViewController just happens to be the example he chose, but the same Q&A would apply if he talked about Servlet and ServletController and HttpServletController.
    – jmort253
    Commented Apr 8, 2012 at 3:11
  • I do this, too, and have also often wondered why I don't see others do it.
    – Izkata
    Commented Apr 8, 2012 at 6:42

3 Answers 3


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.

  • 1
    +1 for DRY violation - seems like a very important point.
    – weronika
    Commented Apr 8, 2012 at 5:55
  • DRY... I prefer the DBABR (Dont Be A Broken Record) principle. Commented Apr 18, 2012 at 21:00

My 2 cents if I understood right your convention (correct me if I did wrong please).

  • I believe it will be hard following up on this convention for larger projects. In an ideal world you would have classes doing small tasks and following up good hiding secret principles leading to couple and cohesion. On the real world what I have seen are classes that tend to do a lot of things. Maybe the name requires two or more words to describe the class. In this case, assuming on CarHondaAccord, say that Honda class was a bigger class name composed of more than one word (e.g. yours, TableView). How would you go about differentiating what is your parent class from what is a composed word? (Is Table a parent class of View?). Maybe you could argue from the context, but I would say I would get confused sometimes. This would increase my effort just to understand the class name.

  • I believe that certain sort of conventions are good to improve maintainability of code on the long run, but you might want to consider how much effort do you put while programming to follow up these conventions. I think that having to run a mini alphabetic order algorithm on my mind every time I would name a subclass could be a burden.

  • Increases redundancy. Consider the statement of a class in code, you not only declare that your class is a type of other class as it is required by the language, but you also overload the same information on the class name. I believe that a code that would be reusable in this case and has a deep tree of inheritance (Maybe software product line code) would suffer greatly using this name convention. I wouldn't want to be reading the deepest classes name at all or writing it either. (Although you could argue about copying and paste or using a cool IDE auto completion to do the trick).

  • I believe communication about certain classes would be reduced to pointing the classes as well, as you would probably have a hard time memorizing each class name fully, as knowing it means you know a path from the root parent class to the deepest child. What about multiple inheritance? Ouch! The size of the class following this convention would require scroll to move around very soon. In fact, one HCI principle is to try and avoid giving users keeping things in their short term memories (those that you memorize something and if anything distract you, 'poof!!' they are gone). This would lead potentially to slips, which might increase errors on your code if classes name are similar (they probably are since most of them are similar. Having them being similar also increases the chances of slips). This discussion occurs on Normans book.

  • Feels less natural. Apple Code Guidelines states this at a certain point for methods name I believe.

  • It doesn't feel OO for me. I want to call my code objects what I call them in the real world. I don't reason about their parental name hierarchy. I would rather care about the names having a meaningful sense to me, that is, making my life easier to understand, than making the computer file directory list easier to show me them ordered.

  • 2
    +1 - OO is about natural language, which makes it easier for humans to process things.
    – jmort253
    Commented Apr 8, 2012 at 3:08

I think this is because in English adjectives come before nouns and you would say I bought a Honda car rather than I bought a car Honda.

If you have long lists of classes, you can move some classes into a new package.

  • "I bought a car, (named) Honda."
    – iammilind
    Commented Apr 8, 2012 at 4:19
  • So if I worked in a Spanish company, CarHonda would be appropriate because adjectives come after nouns in Spanish.
    – JoJo
    Commented Apr 8, 2012 at 21:42
  • 1
    @JoJo imagine the headaches you would have if you worked for an Arab company, writing right to left! Commented Apr 8, 2012 at 21:52
  • 1
    @vitalik It will be even harder working in a Chinese company where they write kanji vertically.
    – JoJo
    Commented Apr 12, 2012 at 6:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.