When I am in a time crunch and I really don't see myself using a parameter again I go with project parameters...but 99% of the time I really see no reason to not just make a shared parameter. It takes little more time to make a shared rather than a project or family parameter and does not have the restrictions that the other two have.

The way I was going about it when i started making my first parametric beam was having shared parameters that are organized based on the element or material that they modify.
For example Group> Concrete , Pamareters> Length Width, Depth etc.
Group> Reinforcing , Parameters> Number of Bars, Bar Diameter, Bar Radius, Rebar info.

There is probably a better way but this was my first stab at it

In terms of naming I was thinking maybe its better to do it in all lower case. It just seems easier to create formulas without having to worry about capitalizing anything. Also, there should be an underscore to denote a space between names, I feel it makes it easier to identify

I´m currently grouping the SP´s just like the hardcoded groups in the properties palette: ie: "Dimensions: Door Width, Door Height, etc." or: "Materials and Finishes = Frame Material, Panel Material, etc."
But I´m open to any suggestions.... really only matters that we agree on *something*

I have a habit of Capitalizing ALL Words In My Naming Conventions... Find it easier to read, and you can contract words WithOutSeperator (and still be able to read it) And SEEK uses this convention too.... But again, I´m open to anything....

Also, I think that I saw somewhere that Aaron uses colons : in the SP´s naming, i.e. "Frame: Width" - Let me see if I can find that again...

He does, but he wouldnt do it again given the choice. You can ONLY do it in Shared Paramters. He does it because he inherited some of them, and redoing them seemed unworth the ROI.

But NEVER EVER EVER use / or - or = or + in any type of parameter. No Parenthesis either. They destroy formulas.

I also use the OOTB categories. I used to do it somewhat similar to JCM's approach until I had to create a Multicategory Schedule which scheduled the length of multiple elements. I found myself with a schedule that had 13 columns of length for all different elements in the schedule.
Now I use as little adding to the name as possible. For instance, I don't use door_width but just width. The fun thing about shared parameters combined with nested components is that this doesn't affect the nested component. So my workflow is this:

Width door = width (shared parameter)
Width panel in nested component = width (shared parameter)
Width panel in host family = panel_width (project parameter referencing the width-parameter in nested component)

This works great in keeping the amount of SP's to a minimum (and your schedules readable).

So, this is my current workflow:

- Group parameters like the OOTB settings. Simply to prevent from having to make a naming convention for the used groups
- All lower cases for naming (or I forget the Capitals half of the time)
- Use underscores instead of spaces (try figuring out what the **** is wrong with your parameter when you accidently typed in 2 spaces in your SP-file and you want to use this in a later formula)
- Keep amount of SP's to a minimum by using SP-names that don't reference the element they are applied to if not strictly necessary.
- If your SP does reference a specific component (door_width), name the element it references first and the actual parameter name second, so it would be door_width and not width_door. Since the SP-screen sorts by alfabet this groups the parameters that reference the same component.
- Nested components using Shared Parameters, if possible host component with project parameters.