Naming convention for new projects [closed]

Answer 1

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.

Answer 2

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.)

Answer 3

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.

Answer 4

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).

Answer 5

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

Answer 6

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.