These best practices reflect recommendations shared by a cross-functional team of seasoned Lookers. These insights come from years of experience working with Looker customers from implementation to long-term success. The practices are written to work for most users and situations, but as always use best judgment when implementing.

Substitution Operators

Substitution operators should be used throughout all LookML files. A LookML model should have only a single reference point to any object in the physical data model. Any subsequent definitions that need to reference that object should do so by pointing to the already-defined LookML object.

${TABLE}.field_name should be used when referencing the underlying database table, for all base dimensions that are pulling data directly from underlying database columns. If a schema or table name changes, this enables a developer to update the schema and/or table name in one place (within the sql_table_name parameter), and have it propagate through the rest of the code.

${field_name} should be used when referencing dimensions or measures that have already been defined within the LookML. If a column name changes, that change will only need to be updated in the sql parameter of the base dimension or measures. That change will then automatically propagate to all other fields that reference the column. For example, if a column name in our database changes from usersid to users_id, we will need to change the reference in Looker. Using ${field_name} means we only need to update one line.

When multiple dimensions and measures reference an existing LookML field with ${TABLE}.field_name, many changes are needed.

dimension: usersid {
  type: number
  sql: ${TABLE}.usersid ;; # Change here
}

measure: this_week_count {
  type: count_distinct
  sql: ${TABLE}.usersid ;; # Change here
  filters: [created_date: "7 days"]
}

measure: this_month_count {
  type: count_distinct
  sql: ${TABLE}.usersid ;; # Change here
  filters: [created_date: "1 month"]
}
 

With the reference ${field_name}, only one change is needed:

dimension: usersid {
  type: number
  sql: ${TABLE}.usersid ;; # Change here
}

measure: this_week_count {
  type: count_distinct
  sql: ${usersid} ;;       #Using ${field_name} to reference the LookML field `usersid`
  filters: [created_date: "7 days"]
}

measure: this_month_count {
  type: count_distinct
  sql: ${usersid} ;;       #Using ${field_name} to reference the LookML field `usersid`
  filters: [created_date: "1 month"]
}
 

For more uses of substitution operators, check out our How to Reference Views and Fields in LookML documentation page.

Field Sets

Use sets for maintaining reusable field lists within the model. Any lists of fields that are repeated, whether via the fields parameter or within drill fields, should be incorporated into sets in order to create a single place in the model in which that field list can be updated or field references changed. You can find more about sets on the set parameter's documentation page.

Avoid Repeating Code

Think of LookML objects as building blocks, and use the extends parameter to combine objects together in different ways without repeating code. Detailed information and examples of reusing code can be found on the Reusing Code with Extends documentation page. Additional examples can be found on the extends (for Views) and extends (for Explores) parameter documentation pages as well as the Using Extensions to Define Joins Community post.

Maintain consistency across Explores by not repeating code in multiple places. Additional ideas on how to accomplish this can be found in the Looker Community topic on Avoiding Inconsistencies across Explores.

Consolidate Items Like Map Layers and Value Formats

Define custom map layers centrally in a LookML file called map_layers.lkml, which can be created by following Looker's documentation on project files, and that can be included as needed across models. Alternatively, add JSON files directly to the repository by dragging and dropping data files into your LookML project, and reference them within the model.

For example, this map layers file can be included in any model in the project with include: "map_layers.base.lkml".

Set any custom value formats centrally within the model. Use the named_value_format parameter to set any custom formats within the model, and then reference those using the value_format_name parameter in dimensions and measures.

Create Development Guidelines

Define development guidelines to make it easier to develop and scale a LookML model. See the Looker Community topic on Example LookML Development Guidelines for a walkthrough of a sample development guideline list. Common guidelines include requirements for:

• Clearly organizing LookML files, so they are consistent and easy to navigate.
• Using comments throughout the views and models, to add context to the LookML that is written.
• Creating documentation within Looker using Markdown files.