This Post Has No Name

Monday, June 19, 2006

One of the hardest tasks in software is finding a good name. Names for variables, classes, libraries, and products requires countless mental cycles - as it should. Names are a serious business. In software, names bring imaginary things to life. Good names lead to readability, shared vocabularies, and emotional attachments. Bad names lead to confusion, pain, and assistance from highly paid consultants.

The Art of Naming Variables

Have you ever wondered how many hours the software world has spent inventing naming standards? You know the "prefix this" and "suffix that" and "start all of these with a capital C" documents. These standards are the perfect method for making Code look Consistent, but always include the rule "use logical and descriptive names". A naming standard is to good names as "use pronouns clearly" is to good grammar.

How to: Bastardize a Common Vocabulary

It's a shame Visual Basic uses keywords like MustInherit and Overridable. The rest of the world talks about abstract classes and virtual functions, but Visual Basic has to be different. They say it's because VB is geared to the developer who wants to add value to their business. Yet the developer who is typing "MustInherit" clearly isn't thinking about a business problem - they are thinking about a class hierarchy. Why shouldn't VB have the same vocabulary as the rest of the OOP world? Ever hear of a MustInherit factory pattern?

Every Time I Hear Your Name

For libraries and frameworks, the naming stakes get even higher. If the framework is going into widespread use, people will encounter the name in book titles, articles, power point slides, and technical conversations. People become attached to the name, as it covers many abstract and conceptual things. Witness the outcry over the Indigo to WCF switch, and the Avalon to WPF switch. Will Atlas stay Atlas, or will Atlas become the ASP.NET Client Side Integration Framework (ACSIF)?

The Name Game

Naming a product is the toughest assignment of all. We need to search trademarks and domain names. We need something that is snappy and looks good on a business card. The safe approach is just to make something up, like FlazBlatter. Someday, there will be a product named FlazBlatter, mark my words….

James Newton-King Monday, June 19, 2006
One of my peeves around naming, which thankfully .NET is very good about, is abbreviating. I hate it when frameworks abbreviate any method over 8 characters, often making them completely unintelligible, all in the name of saving a few keystrokes.

Even ignoring modern IDE features like autocomplete, which means you often only need to type in the first few characters of a name, a developer spends far more time reading code than writing it and abbreviating makes things just that much harder.
scott Monday, June 19, 2006
I hear ya, James. I think it is a framework design guidline to avoid, or at least be careful with, abbreviations.
Milan Negovan Monday, June 19, 2006
I found the .NET Framework Design Guidelines book quite helpful in this respect. They talk about naming of namespaces, classes, variables, and other conventions quite a lot.
Paul Monday, June 19, 2006
The Bastardising of vocabulary ... that's Microsoft for you! ;-)
am Monday, June 19, 2006
Part of the problem with Microsoft's product naming is that they take perfectly good, unique, differnt code names -- things that will actually stick in your head -- and turn them into Microsoft(TM)(R)(C) Windows(TM)(R)(C)<common, non-descriptive English word> for Office(TM)(R)(C).

So the S/N ratio plummets by the time MS Marketing is done. There's no mental purchase there. Who other than *really* gung-ho MS, MS, rah-rah-rah types are supposed to differentiate between WPF, WCF, WWF, WTF... I think their marketing department needs to review Psychology 101.

Anyay, nice posting, the way you've unified all those seemingly different naming tasks is thought-provoking.
scott Monday, June 19, 2006
am: You forogot that the words "Live" and "MSN" seem to crop up randomly in the product names, too.

This just in: Microsoft is renaming themselves in 2008 to the "Windows Manufacturing Company".
Jeff Atwood Monday, June 19, 2006
> The rest of the world talks about abstract classes and virtual functions

Can't agree here. Those terms are for propeller heads, or medieval philosophers, I'm not sure which.

I prefer "nothing" to "null" and "MustInherit" to "abstract". Much easier to understand in plain English.

If you think you prefer terms like "abstract", it's probably because you have Stockholm Syndrome. You've been held hostage so long you've started to sympathize with your captors.
scott Monday, June 19, 2006
Jeff: maybe. I like the idea of a shared vocabulary, it makes it easier to communicate amongst ourselves. VB seems to be the rebel force here, trying to stir things up just to be different.
Pablo Wednesday, July 5, 2006
Granted shared vocabulary is good. How do you explain abstract classes without saying anything like must inherit the class or virtual methods without explaining that they are overiable?
Sachin Joshi Wednesday, July 19, 2006


Sachin Joshi

"Reason can answer questions, but imagination has to ask them."
- Dr. Ralph Gerard
Comments are closed.

My Pluralsight Courses

K.Scott Allen OdeToCode by K. Scott Allen
What JavaScript Developers Should Know About ECMAScript 2015
The Podcast!