Instead of unintelligible names and acronyms for new products and services, is there any other way of naming software that could also say what it is and what it does?

For example, instead of naming a software Abricudabrah or similar which typically means nothing and says nothing about what it does, could there be a naming scheme for instance <what it does>.<what it is>.<id> e.g.

A means database

B means web server

C means a browser plug-in

and then a software could be named A.java.H2 and then you would know that the H2 product is a database in Java and likewise.

closed as primarily opinion-based by gnat, Michael Durrant, Thomas Owens Dec 8 '16 at 11:44

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • But you should use your naming convention on Java which is another software product and not some obscure french dance. – mouviciel Dec 8 '16 at 10:14
  • 1
    You want to put "java" in the "what it is" section? Seriously? What if a product is written in three languages? What if a product line changes its implementation language? Why should the end user bother with the implementation name at all, except for the case where the product's audience are developers? – Doc Brown Dec 8 '16 at 15:46
  • Compare the pharmaceutical industry, which has a random syllable generator for names because there's so many products. – pjc50 Dec 8 '16 at 16:23
  • "There are only two hard things in Computer Science: cache invalidation and naming things." – Sean McSomething Dec 8 '16 at 21:07

Great idea. But its not really in the interests of the people selling the software. I mean would you buy :

  • no mans sky : elite.clone.twelve
  • star citizen : elite.clone.notfinished
  • macbook : pc.without.touchscreen
  • linux : os.without.gui
  • iphone : phone.with.touchscreen.5

the commoditisation of products helps consumers by standardising quality and encouraging competition on price. But as a producer of goods you want people to buy your brand and your product to seem qualitatively different to your competitors

  • 2
    I think you have a naming conflict as well, both star citizen and no mans sky would be named elite.clone.notfinished. – Lasse Vågsæther Karlsen Dec 8 '16 at 9:15

Software names are brands, are marketing. These names aren't intended to be useful. Often, they aren't even unique. But they suggest positive associations, may be puns on other names, and (ideally) are quite clear in context.

I agree that such names are problematic. If you'd give me a random selection of package names from NPM, I would be unable to tell you what most of them are supposed to do. Here are the most starred NPM packages, sorted by whether I consider the name in itself self-explanatory or not.

  • Self-explanatory (11): request, async, gulp-uglify*, gulp-concat*, nodemailer*, gulp-sass*, nodemon*, redis*, body-parser, mysql*, validator.
  • Not self-explanatory (25): express, gulp, lodash, browserify, pm2, commander, mongoose, grunt, socket.io, moment, forever, mocha, bower, chalk, underscore, cheerio, debug, react, passport, bluebird, q, npm, colors, karma, yo.

* These items are not in themselves obvious, but I'll let them pass because the unclear names are references to other projects.

Of course it's easy to pick on JavaScript when talking about project names, but it is (somewhat) possible to do things differently.

The Perl language has a name guideline that would be more to your liking:

What's in a name?

Make sure you choose an appropriate name for your module early on. This will help people find and remember your module, and make programming with your module more intuitive.

When naming your module, consider the following:

  • Be descriptive (i.e. accurately describes the purpose of the module).

  • Be consistent with existing modules.

  • Reflect the functionality of the module, not the implementation.

  • Avoid starting a new top-level hierarchy, especially if a suitable hierarchy already exists under which you could place your module.

perldoc perlmodstyle

Naming Goals

  • Providing Context: […] We can categorize modules, but that categorization lives outside the module and disappears once someone downloads it, blogs about it, or uses it in their code. […] In the author's mind, it's always obvious what the module does and what the name means. Other people don't have that context, and the name needs to provide it.

    […] Almost any abbreviation or acronym is going to be ambiguous. If the first page of Google hits for your initialization isn't about your topic, then you have the wrong name.

  • Describing Key Features: […] What does an HTML module do? Well, you really can't tell from that name. How about HTML::Parser, HTML::TreeBuilder, and HTML::SimpleLinkExtor? […]

  • Distinguishing characteristics: […] How many Config and Getopt modules can you find on CPAN? […] Why should people use your module over modules with very similar names?

PAUSE: On the Naming of Modules

There are a couple of established top-level namespaces like Text::* or WWW::* or Test::* or App::* that encourage authors to categorize their library. If the above unclear npm packages were using such a schema, they would become much clearer: App::gulp, Util::Lodash, Util::Underscore, DateTime::Moment, App::bower, Devel::Debug, Test::Mocha, Test::Karma, ….

Of course it's sometimes necessary to break out of that hierarchy:

Big projects

Some projects, such as Moose, DBI, DateTime, and Catalyst, try to organize the activity under their namespace to ensure everything works together nicely. If you want to add a module to such a project, discuss it on their mailing list. […]

Names to avoid: Top level namespaces

[…] That doesn't mean that all top-level namespaces are bad. For frameworks like Moose, Catalyst, or DBI provide a functionality around an idea rather than a particular low-level or general task. They don't live in a hierarchy because they are large enough to stand on their own.

— ibid.

This still doesn't solve everything. People think that their framework is important enough to merit a top-level name, or they see an existing module that fits their needs and decide to rewrite it because they consider it over-engineered:

The terms Simple, Easy, Reduced, and Tiny are some of the worst parts of the names on CPAN. They all indicate that the module is a variation of another module, but why is that variation interesting? It's usually missing or hiding some features, less flexible than the original, and in most cases, tailored to the task the author needed. What is that task though? Making it easy for you doesn't mean it's easy for the next programmer.

— ibid.

All of this has worked somewhat well – for libraries. The audience of a library is a programmer who is going to reference that name all over their code. But for (user-oriented) applications, languages, or frameworks, a marketable name is more important. For example, why was the grep-like tool ack named ack?

What does ack mean?

Nothing. I wanted a name that was easy to type and that you could pronounce as a single syllable.

— Andy Lester

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