Why Would We Care About QlikView Naming Conventions?

One of the foundational concepts that new developers ask about is QlikView Field naming conventions for fields.

Is there a reason why you used the percentage sign?

Why is this field capitalized and this other field is not?

Is it better to rename our fields in the front end or in the script?

Of course the truth is that you can name fields any way you want. It is completely up to you.

But with all things, there are best practices that dictate a more nuanced approach. Creating logical and consistent data field names for your QlikView and Qlik Sense applications will have many benefits:

• Speeds dashboard development since fields are named in the script
• Groups types of fields together alphabetically to easily locate in lists
• Makes it easier for you or other developers to maintain and adjust existing code
• Enables documents to share infrastructure or to be linked (chained) together
• Creates more professional and readable user experience
• Allows us to hide fields that are extraneous or not needed for the user.

Syntax for Renaming a Field in QlikView or Qlik Sense

How do you rename (or alias) a field in the Qlik script? In case you don’t know it is incredibly simple. Just use the “as” keyword with a space on each side and then insert the new name.

Let’s go through the naming conventions I use and recommend. I would encourage you to adjust and refine to your liking. These best practices can be applied to both QlikView and Qlik Sense.

Renaming Dimensional Fields

Most of the fields in any Qlik application will be dimensional in nature. This means they are there to provide context to your data and allow users to make selections. Some examples of dimension fields:

• Customer
• Year
• ChipSet
• OS
• Item
• Author
• Sales Representative

Any field we can use to slice and dice the data is really a dimension.

So how should we name dimensional fields in QlikView?

The best practice for naming dimensions is to use natural language.

In other words, name the field as the user will want to see it in the UI.

This means instead of date_year we will use Year.

Instead of Customer_Name we will use Customer.

Rather than ItemNum, we might use [Item Num] or [Item Number].

The efficiency to be gained here is that if we name our dimension fields as the user expects to see them, we do not have to spend lots of time renaming the field properly each time we use it in an object in the dashboard. This is not so much an issue in Qlik Sense if we are utilizing Master Item Dimensions, but if we are not or if we are using QlikView, this can be a major time waster.

Another factor you might have recognized is case sensitivity. I much prefer to capitalize the first letter of each word (Camel Case) for fields the user will see. I also add spaces to separate words. Remember that if your field name includes a special character like a space, you must surround the field in quotes or square braces: [Customer Type].

I find this is the most professional and natural case for users to interface with. Another acceptable approach would be to capitalize all the letters of the dimension ie: CUSTOMER. But in my opinion, this can widen fields considerably and could make your design look “clunky”

Whatever you decide, be sure to keep the dimension naming convention consistent across the application.

Would you rather see this?

Or this?

Naming Metric Fields

The approach we will take to appropriately name our expression fields will be considerably different. An expression field or measure or metric is a field in your Qlik data that will be used within the expression dialogs of your charts. It will be the (mostly) numeric fields that we sum up, count and average for example.

Now, within your data source, these fields will be scattered about and might not follow any sort of meaningful naming convention. But in our QlikView and Qlik Sense apps, these fields fill a very important role. So the best practice here is to name them so they appear together in our lists and when the auto-populate features are invoked.

I like to put an “m.” in front of measure fields because I can then easily isolate them when creating expressions in my dashboard

Quantity becomes m.qty.

Price becomes m.price.

ExtendedPrice becomes m.extprice.

I have seen other developers prepend their measures with “#” or with “e” (for expression). All these approaches are valid and create the same efficiency. The reason I like “m.” is because it is easy to type.

The reason for this type of prepended naming becomes obvious when we try to utilize one of these fields in an expression:

As you can see, the list of available expressions is immediately apparent when we begin typing “m.” at which point we can easily choose the metric field we require. And because expressions are always created in the UI, we ALWAYS must name them there, so there is no use in giving a metric field a user-friendly name in the script. Instead we will create measure names with a focus on making it as easy as possible for us developers to create the expressions.

Key Fields and Invisible Fields

The key fields in our application are the fields we will use to join the tables together in our data model. Typically, key fields are integer or concatenated fields that would not make sense for the user to filter on or display in any way. And with the aim of keeping the interface as simple as possible for the user, it would make sense that these fields should be made to simply disappear!

To make a field dissappear for the userrs, we will need to first, prepend these fields with a common character and then set a special system variable to hide these fields from the users.

I like to prepend my key field names with a percentage sign: “%”. One byproduct of this is that all my keys will be easy to identify when scanning through a list of fields. A second advantage is that when sorted alphabetically, these fields will float to the top of the list.

ItemID becomes %ItemID

CustomerID becomes %CustomerID

OrderID & num(Date) becomes %OrderDate

The final advantage of this is really the primary reason for prepending the field. We want to hide these fields from the user. We will need to tell Qlik to do this using a special system variable. This can appear anywhere in your script.

As long as the character inside the quotes matches the character you use to prepend your key fields, these fields will not be shown to users in searches or current selections or be available for objects.

The added benefit of this is that there are sometimes other fields in your data that you might want to hide. So you can really hide any field from a user with this method.

In the example below, I often times will create a “user generated” report that allows users to select from a list of dimensions and a list of expressions to create their own exportable report. I will typically prepend the field list with “%” so that when the user selects the fields to include in the report, they do not appear in the current selections box in the upper left. Very slick if I do say so myself.

Naming Variables

You might also consider consistent naming conventions for your variables. The only advantage here is that it will keep you as the developer straight when utilizing these variables in the dashboard because when displayed in a list, they will follow an alphabetic sort.

I use the following prepending conventions for my variables:

mVariableName               expression definitions

cVariableName                 color expression definitions

vVariableName                 script-side variables

dVariableName                display control flag variables

iVariableName                  user input variables

Final Thoughts

Here are a few links to further reading on the topic of QlikView field naming conventions:

QlikView Addict – User Friendly Field Names in QlikView

QlikView Maven – Translate a Field Name into a User-Friendly Field Label

Hopefully this makes sense and you see the benefits of using field naming conventions in your applications. They provide consistency for the QlikView and Qlik Sense applications in your environment or across all environments you work on. This makes your scripting efforts more efficient. It will definitely make your dashboard design more efficient. And also, it provides some ways to fine-tune your user experience, giving them exactly what they need and nothing else.

Do you use naming conventions that differ from the above? Our readers (and I) would love to hear about them. Add your thoughts on this to the comments below.

Happy Qliking!