Fabio's Opinionated LookML & SQL Style Guide / Ruleset

As a Customer Success Engineer here at Looker, I’ve spent quite a bit of time working on a diverse set of models. More often than not, these are existing models that I did not create, but simply want to contribute a few incremental changes to. Sometimes it’s a walk in the park. Other times, it’s a labyrinthine rabbit hole.

And the difficulty of adding a new thing to a project, if you think about it, is a pretty good indicator of the future speed at which your organization’s analytic capabilities can grow, not to mention how easily you can onboard new analysts and developers, and a number of other success factors.

So, I decided to make the best of my rabbit hole experiences by putting together a style guide and ruleset to help others avoid ever getting into those situations in the first place!

Before we get on the main show, I will extend two words of caution.

  1. In the interest of preventing problems down the road, I will be recommending some practices whose value is not immediately realized. I have tried to put rationales along with all of these rules to help explain why, but nevertheless some rules may be unpopular.

  2. More importantly, this is a first draft and will hopefully be amended and expanded in the future, with your feedback. If you read the guide, I would greatly appreciate some comments here to help me understand where there is room for improvement.

With that, here’s the guide

Update: There is now a linter for this style guide too! Introducing LAMS, a LookML style guide and linter


Awesome work! Definitely will be sharing!

1 Like

Great guide. It will definitely be helpful as we are in the early stage of our Looker deployment!

1 Like

Easy thing to clear up: what do you mean by {n}pk_ ? What are legitimate values of “n”?

Hi Rick! Did you notice the rules can be expanded by clicking on them? (I’ll add some CSS to make the cursor a pointer to make that clearer). Or was the expanded explanation not clear enough? N is supposed to be the number of columns in the key (legitimate values are 0 or any positive integer in base 10)

Uh, no. Thanks for the tip!

Thanks for this - style guides are useful for creating team cohesion. Opinionated is good - if customers disagree, they can create their own variant of the style guide.

One point. You suggest an alias ‘{n}pk_{column}’ for primary keys, e.g. ‘as 1pk_user_id’. Not all databases like identifiers that start with a digit (e.g. oracle, hsqldb). I suggest changing this rule to make it more portable.

That’s a good recommendation on the not starting with a digit. I’ll add it in a note as an acceptable variant for now, and next time I want to publish a “2.0” version with breaking changes and all, I’ll make that the default

1 Like

Thanks for this guide! This is really useful stuff.

I would love to know your opinion on file organization in a LookML repo.

For example, where should I store derived table views? If I have a a base table (base_table.view.lkml) and I want to build a derived table off of it, do I build derived_table_base_table.view.lkml or do I define the view within the base_table.view.lkml.

Hi Tao! I’m glad you’re finding it useful :slight_smile:

I actually don’t have a preferred approach to file naming. However, I do think it’s important to have a predictable way to find views given some characteristics (such as primary key) to prevent duplication of logic. In fact, when writing this, I was considering having a naming convention around file names, but what realized that I actually want to do is to use my lookml parser to automatically build a sort of index of views into the LookML project as a markdown file. It’s on my to-do list!

1 Like