Cassy Freeman‌, Paul Crawford‌ and others along with myself did this at my old company. 

We established our naming conventions for the Workflow Variables in the format like so:

v"datatype""description"

we also added

col"description" for our collections.

and camelCase of course

So we would have vtxtDocumentName, vpplPersonName or colListItemIds.

Brilliantly written article by the way.

Good post and thanks for the examples.  For site/list columns I was taught early on to name them without spaces, otherwise the actual system name inserts "%5Fx0020%5F" for the space, which is difficult to read and I remember it causing problems at times in the past in certain situations.  After the column is created I then change the display name to have a space in it.  I don't have Nintex Forms, so don't know if it looks at the actual column name, or the display name.  I know you see the display name in the workflow designer. 

For my variable naming conventions, I use an abbreviation for the type, followed by an underscore, then the variable name.  Ex: st_Name, mt_Description, c_Tasks, etc.  "st" for single line of text, "mt" for multiple lines of text, "c" for collection.  

Thanks Ryan :)

Interesting point about the column names Brendan.  I checked in the forms designer and, at least to the user, it uses the column display name when referring to column names.

If anyone wants some further reading about the display name vs the static name, this blog post provides a good explanation.

Cheers,

Chris

I've also found Ryan Greenaway‌'s method to work best, especially for debugging if you're trying to save text to a number column for example with datatype in the name.

If only we had constants in O365

One thing to note about variables and Nintex Workflow Cloud. By habit I use my naming convention for variables in a NWC workflow in which I also needed Nintex Mobile App start. So my variables were my start form. Since you (yet) cannot have a different display name, you will need to write out the name of the variable instead of using the naming convention.

We do the same Ryan. Using types in the name also help in locating where a variable is used when you go back to edit weeks later. If done correctly, you know to expect certain types within certain actions. 

Just to add to this blog as an article of helpful links about variables, see ‌

Be careful of the spaces with names. They aren't spaces in the url when they are referenced. It makes it harder when trying to refer to it later. I prefer not using spaces. For example, strFirstName, intAge, etc. Of course this was how I was taught when I started programming.

Bugger!  I imagine that will change as the forms designer for NWC is expanded.  Hopefully! :)

This is a similar issue for O365 start forms, where the variable is displayed and (as far as I can tell so far), not changeable. 

So long, txtProjectName and numProjectCode ... hello Project Name & Project Code.  

Hi,

I work the same way: first create some "internal" column-name and the rename to column; or create the columns with powershell (CSOM), where you can specify the internal and the display-name at once.

This is also true for lists: I would always at first create the list with some "nice" internal name, as this will become part of the URL. Maybe stick with some kind of short-name, to keep the URL less then 260 characters. Then change the display-name of the list to something meaningful for endusers.

This is not as important if you're just working with Nintex (Workflow or Forms), but it becomes a real pain if you're happen to access those kind of column-names (containing space or other special characters like german Umlaute!) in code (e.g. REST, CSOM, SSOM ...). Or if you feel the need to create a custom CAML-query this will hit you as well. 

I omit the "v" for variable usually, but other than that I usually stick to the hungarian notation as well.

Depending on the action/field/... Nintex does show references sometimes as "{WorkflowVariable:intNumber}", which makes it obvious that it's a variable