Shared parameters naming convention

[Charlie_Mex]

What naming convention does your practice use with Shared parameters? 

I have seen the following naming conventions

1.- COMPANY_FRAME_WIDTH

2.- FRAME WIDTH

3.- FRAME_WIDTH

4.- FrameWidth

5.- SP_FRAME_WIDTH        (SP meaning Shared Parameter)

I prefer option number 2, from my point of view I see the following advantages

- User will find it easier to use.

- Refers exclusively to the element in question.

- Uppercase makes it easier to identify as a shared parameter. 

- You don't have to rename the heading in schedules. 

- Keeps the naming convention short, which can be an advantage when using Revit formulas. 

Is there any disadvantage in this naming convention, when using Dynamo, Python scripts, or when working with multiple disciplines to identify content from each team? 

Regards

[ennujozlagam]

better  to use the underline _ ( FRAME_WIDTH) for text.

[RDAOU]

@Charlie_Mex 

Apart from the fact that I find ALL CAPS annoying, there are no disadvantages in terms of Dynamo, Python or coding in general. When being used in Revit formulas, in some cases user would be required to define such parameter with [ ] if it has a space break. I see no advantage in the SP suffix/prefix to identify a Shared Parameter...a parameter is a parameter!!!

For sorting and grouping purposes and considering that one might need to add several dimension parameters (Width/Height/Length...etc) for various parts of a component, I sometimes use the following (Depending on the component):

• Width_Sill
• Width_Frame
• Width_Clear
• ...etc

[Charlie_Mex]

I think using All Caps helps the users to identify visually that these parameters are shared, which was really important in versions before 2022.

What I am trying to create is a system that is natural for users, so when they have to create formulas is easier for them to structure them. Since this is just the start of shared parameters used in the company, it's a really important step that will shape the next 2-5 years. 

If anyone could share an example of how you manage the naming convection of shared parameters in your company, would be helpful. 

[RDAOU]

@Charlie_Mex 

 interesting perspective... but you want to look at a parameter to say it is shares and then what? 

I mean what good does that do or what kind of value does it add to you model or user experience other than knowing you can tag it (something which 90% of the time users do not need to do)...If it is shared it will show up in the Fields menu anyways

[mhiserZFHXS]

Someone woke up on the wrong side of the bed.

I'd say knowing what can and can't be tagged is helpful. If you want to add a parameter to a schedule, you can quickly tell if its ready to go or if you need to make a new shared one.

Also, I added our firm acronym to the start of all of our shared parameters so that it is easy to tell that they are indeed ours. Shared parameters from imported families may also utilize all caps, so seeing the firm at the start is the only for sure way to know its ours. Of course the best thing to do is create your own families so you know exactly what you have.

[RDAOU]

---

@mhiserZFHXS wrote:

Someone woke up on the wrong side of the bed.

I'd say knowing what can and can't be tagged is helpful. If you want to add a parameter to a schedule, you can quickly tell if its ready to go or if you need to make a new shared one.

Also, I added our firm acronym to the start of all of our shared parameters so that it is easy to tell that they are indeed ours. Shared parameters from imported families may also utilize all caps, so seeing the firm at the start is the only for sure way to know its ours. Of course the best thing to do is create your own families so you know exactly what you have.

---

Hopefully your employer wont visit this forum and see what you waste your time on 🙂

[HVAC-Novice · Accepted solution]

My first advice is to make a list of all the Parameters (shared or project) that you create. I have a spreadsheet to track all the parameters, what unit they use, and what group they are in. I also track what type of families I use them in. That way you don't create more than you need. Before you create tons of new parameters, have a plan. 

For naming I arbitrarily decided to call them "SHARED NAME". So if I see a capitalized parameter, I know I created it. And they are easy to find when building schedules etc. since they all sort alphabetically under "SHARED". Obviously you can use your company name or whatever works for YOU.

Families from 3rd parties need to be cleaned up and YOUR parameters added if your schedules or tags depend on them. Families from 3rd party often are amess. I end up deleting many useless parameters, or convert their shared parameters to family parameters. That way they don't clutter up your schedule builder etc. Like if you get a unit heater from manufacturer A, and one from manufacturer B, you need them to work with your scheme. 

[Charlie_Mex]

thank you @mhiserZFHXS and @HVAC-Novice 

Your responses gave me good ideas. I think the excel file would be great now that we are starting to implement the parameters in our practice. 

[bryan-s]

Hi Bim Padawan,
My personal top 3 tips when working with Share Parameter ; 
1. Use Unique identifyer like IFC_Parameter XX, CObie_Parameter XX (or SHARED_, etc) for Share Parameter. It helps user or consultants (of all level) to be clearer/quicker on what is your Share Parameter and not OOTB or Project Parameter. It also helps in reading evolving BIM Pratices or Manager (BIM Manager A = AA_Parameter, B =  BB_Parameter or Supersede = SS_Parameter)

2. There will be Share Parameter for repeated Categories that can be used ie ; XX_Thickness, XX_Integer, XX_Default Value, XX_Finish Type, XX_Created By/On, XX_Item Code / XX_Thumbnail, XX_Frame_Width (which you can group as General).

3. These days you can hack Share Parameter using Project Parameter as long as the text matches ; for schedule, input values, etc etc. (There is still limitations or benefit that applies to Share Parameter like tagging, labelling System Annotation Family, locking parameter, etc etc) . I much prefer to use and create Share Parameter as little as possible. Share Parameter is still finicky with Renaming, Reordering / Sorting, Filtering, Combining Values and writing in Formulas. What can Share Parameter do ; that Project or Family Parameter cannot?

4. I lean more prefably on Power Users over BIM Managers. I tend to design my system around this ethos. 

snake_case is the prefer long standing coding pratices particularly with Revit for Phyton along with other coding languages like PascalCase or Kebab-case. What you prefer is call MACRO_CASE or CAPITAL_SNAKE_CASE (SCREAMING_ SNAKE_CASE)

I use a Sentence_Upper_Snake Case. 

Hope it helps 🙂