Qlik Community

Ask a Question

App Development

Discussion board where members can learn more about Qlik Sense App Development and Usage.

Join us for a live Q&A! September 21, 10 AM ET - Onboarding Fast in Qlik Sense SaaS! REGISTER
Showing results for 
Search instead for 
Did you mean: 
Creator III
Creator III

Writing more readable qlik syntax

Hello everybody,

recently I also learnt more about DAX and PowerBi. I was very astonished how well you can write your DAX-Code and that there are actually two very good convention : writing in short lines or writing in long lines.  You also has these vertical lines for indentation.

This is really something I'm missing in Qlik. Code syntax from others are sometimes really hard to read. And there is also no common convention in the qlik community. And with qlik's own set analysis is really hard to say where to put your commas and indentation.

If I missed any common practice please forgive me, and  I hope you can show me a few examples. Or what you find most practical within Qlik.

Thank you. 

1 Reply


Qlik supports something for large organizations called a Center of Excellence. Their purpose within organizations is to set the standards that fit for the organizations. 

For example if I want to transform a few fields from a table I can either use a preceding load, or I can do a self join after the table has been loaded. The preceding load style is natural to me, but for others self join might be the way to go. 

One of the hardest things to standardize is the indention and CASE of the script. 

Qlik can do a LOAD in a long line: Load Field1, Field2, Field3, Field4, Field 5

Or you can utilize indent: 







I always prefer the indents so that I can quickly comment any fields out that I don't want or copy paste them elsewhere. Same goes for NESTED IF STATEMENTS. Sure I can write it all on 1 line, but I hate that. Nobody can come behind me and figure it out. 

The experienced Qlikkies responding here all have their own styles. So if I post code it will have a certain look, while someone equally proficient may have another. 

It's more than just style/aesthetics. The real key to Qlik is performance. So let's imagine someone asks for help with a complicated expression inside of a chart. Some will simply correct the syntax. While I will generally always advocate for their putting the complex code into the load script instead so that their User Interface is faster. The person asking the question then gets both options. Quick and Dirty solve the problem for now, but they also then get the choice to improve the speed of the experience for the end user.