Well, I know that many S/W engineers don’t care about naming for some concept. But naming is very important because it speaks for itself about what it is for, for what you can use it, and so on.
Because well-named terminology helps smooth flowing or transitioning across multiple related concepts, naming well helps a framework easier to understand and reduces human errors in applying those features represented by those terminologies for.
I’ve written code for more than 20 years. So far, I put my hands on many technologies, languages and frameworks from different companies.
Borland, Symantec, Apple, MS, IBM, and many other open source project organizations to name the few. So, I’m qualified to compare them.
However, consistently, it was only Apple which was good at that. More interestingly, when a company put some proper naming for their classes, architecture etc, how to use them was also easy and overall architecture was more well defined and refined.
I think it’s not coincidental. Once one has rigid and clear idea on a target concept, one can name it properly and design its architecture clearly.
I remember that I wrote about MS’s awkward naming on some of their technology a while ago.
Today, I’d like to take an example from Google.
I made up my mind to take a look at Android SDK more deeply to be able to write actual code ( not just read and understand code ) for Android.
While doing that I ran into a few odd names for their classes and architecture.
“Activity” and “Intention” are good examples.
While working for many companies, I noticed that people just pick function/method names with “noun” form. Do you know what’s wrong about it?
Method and functions are for “doing” or “action”. So, it’s better to have “verb” form. While variables are good to be in “noun” form.
By doing so, code you write starts to be “self-explanatory” or “self-documented”. And it can reduce human mistake in writing code.
Now, let’s pick “Activity”. What kind of feeling you get?
Isn’t it something like, “it’s for DOING something” not “what it is”, or “being”.
So, if it is to mean “event handler” or “transition between views” or “collection of methods to be executed”, it’s easier to memorize the concept of “Activity” and to use the memorized concept.
However, in Android terminology, it’s more about “things to be presented visually.”
In other words, it’s “View” or “Window” on other frameworks.
For example, on Win32/MFC platform, you design a “Window” resource and it has a “View” internally. On Cocoa ( for iOS ) you design UIView. In other words, you put some buttons and text lables on an instance of a UIView. On Cocoa for Mac, you first put a Window and it has NSView in it just like that of Win32/MFC.
However, if you open “res > layout” folder of an Android project, there can be “Activity” xml files which describes those visual stuffs to be presented.
So, “Activity” is not about “action” between views or windows, or action/event handlers.
Well, Google people can defend this like.. “Well, things are happening on a pane presented as view. So, we see a View as a playground on which many actions are happening. So, Activity makes sense.” Well… even though I admit it, it still feels more relevant if “Action” means the “What’s happening on those panes”, not the “pane” itself.
Also, “Intention” is also good example. What you can think of when you heard of “Intention”.
“Hmmm… It’s for presenting what you are going to do (probably) next time.”
Well… it turned out that it’s for tossing data between event handlers and “Activity” or can be anything for passing parameters.
Well… then why do they “invent” such a new class? Wouldn’t it be better to utilize some terminology to mean “data”?
Or you can say, “Wouldn’t it be better to pass them as parameters?”
Well.. yes. But at least, if there are lots of things to toss across entities in a program, sometimes it’s better to embrace in a container and just pass a few container instant. But anyway…
In Cocoa term, “Intention” looks to be implemented using “dictionary” or in general CS term, “hash” table.
In MFC term, it will be CMap. The common naming strategy for them are the naming is based on “data type”. Because it can be used for any purpose, it’s better to have generic name. Now let’s think about “Intention”. Hmm.. is it as generic as “hash table”, “NSDictionary”, “CMap”, “CArray” etc?
No way. Also, there is already well established terminology for it, “parameter”. Then why they invent a new one “Intention”?
If I were a Google engineer, I would name it, for example, “Param”, or can be a little more creative with same approach.
Overall, I’m sorry to say this but S/W architecture portrayed from the SDK doesn’t look good either. It feels like it’s overly complicated.
It feels like my first day of seeing Mozilla CORBA-like object brokering code or MS COM. It’s like that something can be done more simply is done in hard way.
Well… making an egg stand is difficult if you think of it from the scratch for yourself. Once you know the answer, it turned out to be very simple.
However, for architecting thins like Android OS, there were a lot of existing solutions and models they can look up.
It looks like that.. it’s done by small group of people haphazardly. ( Umm.. I know the history of development of Android. )
If they keep make this architecture evolve, who knows? Probably they can run into a wall someday, which is very hard to break.