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.
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.
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