Best practices for shape naming and tracking?

[kennyj]

As I continually (though not continuously), pound my head on the nail of shape design, I often seem to forget which specific nails (shapes) I've managed to evolve to differing levels of functionality. Sometimes -- ok, a lot of times, I'm proud of my progress on a particular shape, but when I chance to have a need to dive back into that one, I've forgotten exactly what method, etc; I had used at the time, and I'm therefore having to go back and reverse engineer my own shape or start over on it.

Also, as I need to reference various shapes, I may find in their properties that their name has evolved from some other shape further down the chain that I might have used initially as a base, but which I don't need cluttering up the current shape's properties. Further, I begin to notice that using a long descriptive name in the stencil isn't necessarily so handy when working at a lower level.

I'm curious if some of you more advanced users / developers could chime in and throw down some ideas of the  hows, whys, and what-fors, of your approach to shape naming conventions, and/or your method(s) of tracking/documenting your shapes for your own future benefit, so you don't waste so much time when you need to recall such things in the future???

Or - perhaps there are some good established standards / best practices along this line that you could point me at?

TIA for any help/suggestions/discussion shedding light on this area.

[Yacine]

not really!
My personal experience is that splitting the problem in small manageable pieces is best for maintenance and scalability issues.
Otherwise, even if names get longer, readable code is always better.
HTH,Y.

[Jumpy]

If I know, that a certain shape will evolve over time, I add a User defined cell User.Version to the shape. In a documentaion, if neccessary, I save the changes between the versions. I often use it, to automatically change old shapes to new shapes, based on version numbers, in older drawings.