Style Rules

The Spectacles Style Validator supports the following rules out of the box. Rule codes begin with the letter of the LookML entity they apply to. For example, rules starting with V are view-related rules.

For each rule, we've included a rationale for why we've implemented the rule, though you can easily ignore rules you disagree with or modify them via custom rules.

Code	Title	Rationale
D100	Yesno dimension doesn't start with 'is_' or 'has_'	Wording the name of a yesno dimension as a question makes it clear to the user what a yes or no value represents.
D101	Dimension name not in snake case	Dimension names should match the conventional format, which is snake case—words in lowercase, separated by underscores. For example, order_id instead of orderId or OrderID.
D106	Dimension not in alphabetical order	Sort dimensions alphabetically to make it easier to find a dimension while scrolling through a view file. A dimension or dimension group violates this rule if it is not alphabetically sorted with respect to the previous dimension or dimension group. Primary keys are excluded from the set of dimensions used to determine alphabetical order.
D107	Primary key dimension not the first dimension in this view	The primary key should be listed first in a view so developers quickly understand the grain of the view and what a single record represents.
D200	Dimension group name ends with redundant word	When Looker creates the underlying dimensions, Looker appends the name of the timeframe to the dimension group name. For example, for a dimension group called order_date, Looker will create dimensions with redundant names: order_date_date, order_date_month, order_date_year, etc. Instead, use order as the dimension group name, which becomes order_date, order_month, etc.
D301	Visible dimension missing description	Dimensions that are visible in the Explore page should have a description so users understand how and why to use them, along with any caveats.
D302	Primary key dimension not hidden	Primary keys are not typically used directly in Explores because users are more interested in aggregates like measures, which reduce the grain beyond the grain of the primary key. Thus, these dimensions should be hidden.
D303	Dimension label includes redundant "Yes/No"	For yesno dimensions, Looker adds "Yes/No" to the end of the dimension's label by default, so there's no need to include it in the label.
E100	Explore doesn't declare fields	When fields are explicitly defined, LookML developers can easily identify the fields included in the Explore without having to reference the view file or loading the Explore page. This is especially helpful when the Explore includes multiple joins and a subset of fields from each joined model.
E111	Explore missing label	Explores should define a label to provide a user-friendly name for the Explore in menus. Looker generates title-cased names for Explores based on the name in LookML, but these names aren't always useful for users. For example, an auto-generated Explore name Prod Sessions L3d (generated from explore: prod_sessions_l3d) is not as succinct or informational as Web Sessions.
I100	Include uses a wildcard	Including all views using a wildcard (e.g. *.view) slows down LookML compilation and validation. Instead, explicitly include the specific views that you need.
J100	Join doesn't define its relationship explicitly	If the relationship parameter for a join is omitted, Looker will use a default relationship of many_to_one. However, it's better to define the relationship explicitly so that developers scanning the code can quickly understand the join. Explicitly defining the relationship can also help prevent errors caused by mistyping or using the wrong columns in the join condition.
M100	Name of count measure doesn't start with 'count_'	You should explicitly state the aggregation type in the dimension name because it makes it easier for other developers and Explore users to understand how the measure is calculated.
M101	Name of sum measure doesn't start with 'total_' or 'sum_'	You should explicitly state the aggregation type in the dimension name because it makes it easier for other developers and Explore users to understand how the measure is calculated.
M102	Name of average measure doesn't start with 'avg_' or 'average_'	You should explicitly state the aggregation type in the dimension name because it makes it easier for other developers and Explore users to understand how the measure is calculated.
M103	Measure name not in snake case	Measure names should match the conventional format, which is snake case—words in lowercase, separated by underscores. For example, count_orders instead of OrderCount.
M106	Measure not in alphabetical order	Sort measures alphabetically to make it easier to find a measure while scrolling through a view file. A measure violates this rule if it is not alphabetically sorted with respect to the previous measure.
M110	Measure references table column directly	Measures should not directly reference table columns, but should instead reference dimensions that reference table columns. This way, the dimension can be a layer of abstraction and single source of truth for all measures that reference it.
M112	Visible measure missing description	Measures that are visible in the Explore page should have a description so users understand how and why to use them, along with any caveats.
V100	View name not in snake case	View names should match the conventional format, which is snake case—words in lowercase, separated by underscores. For example, all_orders instead of allOrders or AllOrders.
V110	View must define at least one primary key dimension	Views must define a primary key so that any Explores that reference them can take advantage of symmetric aggregates and join them properly to views. This rule only applies to views that have defined a sql_table_name or derived_table parameter.
V111	View missing label	Views should define a label to provide a user-friendly name for the view in Explores. Looker generates title-cased names for views based on the view name in LookML, but these names aren't always useful for users in Explores. For example, an auto-generated view name Prod Sessions L3d (generated from view: prod_sessions_l3d) is not as succinct or informational as Web Sessions.
V112	View uses the same table as another view	Views should not have the same sql_table_name because two views with the same table name are effectively the same view. Instead, consolidate these views into a single view.
V113	Name of persistent derived table view doesn't start with 'pdt_'	Views that define persistent derived tables should be prefixed to make it easy to identify views based on PDTs.