I nomi di software sono marchi, sono marketing. Questi nomi non sono pensati per essere utili. Spesso, non sono nemmeno unici. Ma suggeriscono associazioni positive, potrebbero essere giochi di parole su altri nomi e (idealmente) sono abbastanza chiari nel loro contesto.
Sono d'accordo sul fatto che tali nomi siano problematici. Se mi dessi una selezione casuale di nomi di pacchetti da NPM, non sarei in grado di dirti ciò che la maggior parte di loro dovrebbe fare. Ecco i pacchetti NPM più speciali, ordinati in base al fatto che consideri il nome di per sé autoesplicativo o meno.
- Auto-esplicativo (11): richiesta, asincrona, gulp-uglify *, gulp-concat *, nodemailer *, gulp-sass *, nodemon *, redis *, body-parser, mysql *, validator.
- Non auto esplicativo (25): express, gulp, lodash, browserify, pm2, comandante, mangusta, grunt, socket.io, moment, forever, mocha, bower, chalk, underscore, cheerio, debug, react, passport , bluebird, q, npm, colors, karma, yo.
* Questi elementi non sono di per sé ovvi, ma li lascerò passare perché i nomi non chiari sono riferimenti a altri progetti.
Ovviamente è facile scegliere JavaScript quando si parla di nomi di progetti, ma è (in qualche modo) possibile fare le cose in modo diverso.
Il linguaggio Perl ha una linea guida del nome che sarebbe più di tuo gradimento:
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
Ci sono un paio di namespace di primo livello affermati come Text::* o WWW::* o Test::* o App::* che incoraggiano gli autori a classificare la loro libreria. Se i precedenti pacchetti npm non chiari usavano tale schema, sarebbero diventati molto più chiari: App :: gulp, Util :: Lodash, Util :: Underscore, DateTime :: Moment, App :: bower, Devel :: Debug, Test: : Mocha, Test :: Karma, ....
Ovviamente a volte è necessario uscire da quella gerarchia:
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.
Questo ancora non risolve tutto. Le persone pensano che il loro framework sia abbastanza importante da meritare un nome di alto livello, o vedono un modulo esistente che si adatta alle loro esigenze e decide di riscriverlo perché lo considerano sovra-ingegnerizzato:
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.
Tutto ciò ha funzionato abbastanza bene - per le biblioteche. Il pubblico di una biblioteca è un programmatore che farà riferimento a quel nome su tutto il codice. Ma per le applicazioni, le lingue o le strutture (orientate all'utente), un nome commercializzabile è più importante. Ad esempio, perché lo strumento ack di grep è stato chiamato 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