Naming convention for new projects [closed]

问题

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 6 months ago.

I've tried several times to come with an answer to this question. I'm not happy with how projects are named in my shop, they are usually random named after some of these items:

• the client
• some technology used/ or expected to be used inside the project
• some acronyms for the business case the project would relate to
• some names from the domain the project would be in

I find several drawbacks with those approaches:

• the word pool quickly dries up when you have many similar projects
• having the client name inside the project makes it harder to have it abstracted to a generic product
• the acronyms usually sound horrific
• there are many projects that would not pass the prototype phase, and because of this they don't get a proper name
• it's hard to name a project before you know exactly what it does, so most of the time the name picked for the svn and issue tracking project are bad ones.

Please tell me:

What is your naming convention in your shop, are you happy with it, and what would you choose if it were up to you?

Thank you!

回答1:

Whats in the name? EVERYTHING. Make sure the name is interesting, unique and shows the worth of the product you are making. Names based on functionality is the way to go, but it should not define what are you doing rather a single word term that has somehow has a relation with what you are developing.

I often pick my project names in local language (urdu in my case).

Even if you have to insert client name, usually the product would be called ignoring the client name so it doesnt matter much if you pick strong name for your product.

Just to give an example, I named the chess engine I wrote "Shaatir". In urdu it means

1. Very Strong chess player
2. A Cunning/Clever person
3. Someone who lay down traps
4. Wicked.

Each one of the meaning somehow relates to my program.

Edit: You can also add a slogan to your product. Not sure why the idea is not so popular in the software industry. There are few examples though. Like "UBUNTU- Linux for human beings". Adds spice to your product.

回答2:

We name projects in this way:

1. 4 Number Year
2. 3 Letter Client Code (That Big Company might be TBC)
3. Project Sequence Number, if its the first project it would be 0001.

So that project would look like this: 2012-TBC-0001

I find that this is a great way to make sure that everything in our office stays straight. The project number is easy to dissect and follows this project through to completion and billing. Its easy to reference and catalog.

回答3:

I find that naming projects after "functionality" instead of specific clients or technology etc is a big help in this regards. In the .NET world, it's almost customary to begin the name of each project after the owner of the code, for instance MyCompanyName."some_functionality".exe

As a developer, I find I often have a hard time choosing an appropriate term for some set of functions, but when we attempt early on to name something as close to function as possible, then it's not so difficult. It's part of the "clean code" development process.

There are times when it does make sense to name projects after a particular technology, if such a project name would create a definite boundary of understanding of what or where the project is used. For instance, ideally you would not group hardware related functionality into a vendor specific project, but rather perhaps by "function", which could be printers, scanners etc.

Really, we should use the basic principle of being consistent. If we are consistent in how we group and name projects, the barrior between clients are our products have lower learning curves and better adoption rates.

回答4:

Our SVN server has a flat folder of projects. So they look like so:

internal-<something>-system
client-<client name>

It works great, IMO. Directory structure on the servers is simply the domain name. For my development computer, I follow the naming convention of the SVN server. Don't try to stuff everything into different folders - a simple, consistent, prefix can do wonders for organization. For internal items, there isn't anything wrong with generic project names ("Time Manager" "Finance Manager") and such (so that the folders would be "internal-time-manager" and "internal-finance-manager" and so on).

回答5:

We allocate a project number (P and then five digits) which is how the SVN, issue tracking, and document repositories are named; then the project has an informal name which is normally some humorous anagram or phrase arrived at by word association from the client name, what the project is for, etc.

This means that the names are hidden from the client (we just refer to the project number) but we have an easier way to refer to it internally that doesn't involve everyone remembering which project has which number!

There's usually an email round to the project team to get names suggested near the beginning, and the best suggestion is picked.

Some of my favourites included two Base Station projects which were named "Taoist Beans" and "Bonsai Teats".

回答6:

One approach woth considering is the "codename" approach - give your projects internal codenames that have less to do with what the project is about, but sound better. This will make your own work easier. When you a release is coming near, have the marketing department come up with a "real" name.

This of course means that the "real" name has to be configurable in the project from day one, so that in the end you can just change one line and recompile.

This is similar to Vicky's approach. Many large companies seem to follow this too (like Microsoft).

回答7:

I've been pondering this myself for the past few nights for my Subversion repository setup. What about this. I helped to start a small computer shop which led me to the coding, so this is based more on experience than logic. You all should already have a unique ID for your clients for records anyway, so leverage that. Dedicate 000000 or equivalent to in-house software or official releases for sale. All other numbers will be for a custom job from the corresponding client, like websites. I should clarify... below is the directory structure. Hope this helps. :)

000000 - (Client# always belongs to: Inhouse)
    <In-House Project1: Codename/Release Name>
        <Files> (Trunk, Branch, Tags, etc.)
    <In-House Project2: Codename/Release Name>
        <Files> (Trunk, Branch, Tags, etc.)
000001 - (Client# belongs to: John Doe in NC according to records.)
    <One of John's Projects: Sensible Name>
        <Files> (Trunk, Branch, Tags, etc.)
    <Another of John's Projects: Sensible Name>
        <Files> (Trunk, Branch, Tags, etc.)
{...}
002731 - (Client# belongs to: John Doe in LA according to records.)
    <One of John's Projects: Sensible Name>
        <Files> (Trunk, Branch, Tags, etc.)
    <Another of John's Projects: Sensible Name>
        <Files> (Trunk, Branch, Tags, etc.)

回答8:

I've no convention, usually project name is a contraction of customername and a contracted description of the project like "matforming" or "bottlemeasurer". Sometimes if we work for multiple departments or project groups at that customer we extra qualify it with department.

That leads a bit to the same problem (first project often gets the "client" name without department qualification), but IMHO that can't be avoided. Fiddling out the company structure of a new client while only doing a prospect is a bridge to far.

Sometimes the descriptions are also a problem, when you start developing variants on an existing product, or second generations. But that is also quite difficult to predict.

回答9:

i usually devide my projects per client since we have multiple projects per client sometimes, but never do we use the name of that customer inside the naming of the project.

therefore with your wordlist you will only run dry per client. and you need a lot of projects for 1 client in order to run dry that fast.

so customer x can have a businesscardgenerator tool, as can customer y and usually for customer y we start from the tool used by customer x and throw in a whole new template. add some custom fields and properties if not possible then we of course have to start over.

so in general we have a folderstructure for the names you mention and then the project name is actually a very short description of what the project does OR, the project name is the actual project name that the client intends to give to the site/tool/... though we are currently using the first for new projects, we still have left-over projects from before we implemented this use.

intern/projectX/doc
intern/projectX/resources
intern/projectX/media
intern/projectX/code

extern/clientX/projectY/doc
extern/clientX/projectY/resources
extern/clientX/projectY/media
extern/clientX/projectY/code

回答10:

I am in favour of the "codename-approach" but with added emphasis on including functionality and wittyness. Both for making it easy to remember what the project is about.

And then create additional hierarchical structures that sort by logic relations like "customer", "year", and such. You may want to introduce either some standard procedures for project creation or (considering that you are in the automation business) some automation.

(It might be that there are already systems existing out there to do so, I remember some presentation related to some envisioned filesystem in Longhorn that I attended years ago.)

来源：https://stackoverflow.com/questions/1130075/naming-convention-for-new-projects