Ryan Goodrich home

Controller is Probably a Bad Name

In the world of Model View Controller and web development, you end up with a codebase where every class ends in either Model, View or Controller. I have wrote a bit in the past about how you really should not think of Unity projects in an MVC context, and I don’t think most people at this point in time do. Much of the web development world itself has even moved past the MVC conceptualization with React. React actually has an architectural perspective more similar to Unity, in that it is all about composing more generic components.

However I still come across Unity projects where every single component ends in Controller. Which is really just unnecessary. Scroll down the list of all components that ship with Unity. Imagine if each one had ‘Controller’ appended to the end, ApplicationController, ClothController, FlareController. That seems pretty silly doesn’t? But yet some people think they need to put the name Controller on the end of every component which controls something. I contend using the term Controller to describe a component that controls something is probably bad naming. Controller is such a non-descriptive, generic and borderline irrelevant name. It’s only one level more descriptive than appending “Script” on the end of your script name. There are so many more descriptive names for a component. Using these more descriptive names I think will both aid you in better separation of concerns in your architecture, and also make your code easier to follow.

To further illustrate I have compiled a list of nouns that could be used to name components.

The following list of component names is more generic, but may be unavoidable. I would content though if you are doing it correctly only a small percentage of your components should carry one of these names.

By no means consider this list some kind of absolute reference. If you end up naming a component ‘GroupManagerWrapperServiceSystem’ then I think you really missed the point.

Rather, I am trying to illustrate how many other options exist to name components, and also objects. This is an inexact art, but I contend it is really one of the most important things to do correctly. You should always strive to name components and objects as specifically and minimally as possible.

There is a quote that has floated around for a while that goes, “There are only two hard things in Computer Science: cache invalidation and naming things.” I don’t know so much about cache invalidation as the primary one. But naming things is something I would put high up on the list of difficult to get correct things that most do not realize the depth nor importance of. An idealism in Object-Orientation is if you can name all of your objects well enough, you do not need documentation, because each objects name already describes so well it’s role in the mechanics of the entire system. In practice I don’t think you can ever get away without any documentation, but a system with good names makes a huge difference in the ease of maintaining it and also collaborating with others. Good names also greatly aid you in conceiving of better architecture and better separation of concerns, which is why it is important to put effort towards this from the very beginning. Poorly performing methods in a class can always be refactored, it is easier to correct that at any point. However if you used poor naming, and thus have poor taxonomy through your entire system design, then you probably ended up with poor separation of concerns. Then to correct that would probably require a substantial re-architecture and refactoring of much of the system.