Why wouldn’t you? Qlik has its own editor accessed through a browser which works well. You’re script is colour coded, auto completions are suggested and you can organise your code into tabs.

So why use a text editor made by a third party? Well if you’re working with multiple developers (especially across geographical locations) and you’re promoting your work through multiple Qlik server clusters (for example: Dev, UAT, QA, Prod) then you may want to consider changing your development tool.

Choice of Editor

These are programs you download and install separately to Qlik, most are free and you only need one. You just have to decide which is your favourite.

NotePad++, Atom, Visual Studio Code, sublime text, UltraEdit…. the list is endless. Many come with special features to help you become more efficient, link directly with other tools such as GitHub, in fact many can be expanded by importing modules, including Qlik syntax so you’ll still get autocomplete and syntax help.

Key Benefits:

• Customise every feature to your liking and install any number of third-party extensions.
• IntelliSense for programming languages – Many as Standard and Qlik can be download for free
• Integrated Version Control (Built-in Git):-
• Side by Side Editing on different files
• Project Folders quickly open and close related file
• Easier on the eye (light text on dark background by default)
• Only use one editor for Qlik, extensions and mashups
• They’re FREE (well most are)!

 

Using with Qlik

Editors just deal with your code. You still need an app for the front end visualisation but your script is saved in a txt or qvs file. The dashboard references the file in the code but then all the code editing in done using the aforementioned Editing programs (I use Visual Studio Code)

$(Must_Include=lib://library\codescript.qvs);

This has been around for ages. Back in the days of QlikView developers used to use the include and must include commands to bring in code that’s repeatedly used across several dashboard. Sometimes though it can be overused. I’d always ague for a limited use of these type of statements. If overused I feel they only serve to confuse, I recently opened a Qlik script file to debug the code to be faced with this:

 

It got worse, when I opened the txt files they were each made up of several subroutines. The last include script executed these subroutines….. by calling subroutines one at time (but not all of them).

Okay so I’m drifting off the point perhaps with this extreme example but I needed to get it out of my system!

For the purpose of what we’re trying to achieve here trying and keep your include to ideally one, max three and don’t call includes from within includes or people will start calling you names from behind your back!!!

 

Script files can promoted through server infrastructural with ease

If you were to keep your script in the Sense Application then promoting that from your Development to Production server you’d have to export the application from one QMC and then import to the other. If you had data in the application you’d probably first need to remove it or copying the file could take hours. That’s several steps each time you want to promote a change. By having the script in a simple file you just copy it from one drive location to another. Job done!

 

Using GitHub multiple people from any location can work on changes

If your script is in a text file you can manage changes and versions using a tool such as GitHub which can also be linked to workflow tools such as Jira which opens up a whole world of possibilities around version control and collaborative working.

 

Remove Duplication

Some code can be reused many time such as my audit log code or maybe a variable reader. It could even be the main piece of code that drives all the standard extract process, checks made, where to store all sorts of things really. If you reuse code over many apps and any future changes should apply to all then this is a good way to go (as was the same in QlikView times)

 

Ease of working

Different text editors have features that allow for speedy editing and improved workflow. For example holding the ‘Alt’ key and selection cursor positions with your mouse means you can type the same text in several places at once. Below I’m working on a Qlik mashup with a simple HTML table extension. I’m using a spit screen to edit two files at once and I also have quick access to all the other files in the project:

Here I’m working with files from two projects which are shown in the yellow highlighted area. The main text area is split into two parts. Red and Blue highlighted, one for each file. I could have more panes by simply anchoring the text windows how I want them

 

One text editor

In the above point I talked about extensions and mashups. Well having a split screen could also work if you’re editing two Qlik codes files also. However, soon you may find yourself creating more advanced code and between us the ‘Dev Hub’ thatch shipped with Qlik really isn’t very helpful once you really start doing some heavy coding. Best to know and use one system well!

 

File Name Best Practice

Even with all these benefits it still comes with a warning or you’ll end up like the first example. You need to think about how many include statements can be in a single Sense Application. The earlier bad example had far too many. Most should be one include per application, possible two or three as an exception. Also, think about the naming convention not only of the script but how that relates to the application. An example process may be:

Sense Application Name	Script File	Description
Extract Sales Orders	codeETL_ExtractSalesOrders	Extract and Store Sales Fact Table
Extract Sales Product Reference	codeETL_ExtractProductReference	Extract and Store Product Reference Table
Transform Sales Master	codeETL_TransformSalesMaster	Load and transform sales QVD’s into final fact table
Standard Calendar	codeCalendar	Autogenerate a standard calendar
Sales Dashboard	codeAPP_SalesDashboard codeVariableLoad	Load all qvds required for sales dashboard (no transforming) Loads variables from external excel workbook

In the above example the first four applications only one line of code in their script which is an include statement pointing to the script file.

The final application has two links. That makes sense though as you’d want to load the data and the variables in to the final User Interface application. Again, follow my process for organising your ETL This whole topic need more detailed explanation although hopefully this serves as a good starting point. Over coming posts I’ll be expanding on the ideas here with a lot more detail.