These best practices reflect recommendations that were 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 your best judgment when implementing any of the recommendations shared on this page.

LookML Dos

• Do: Define the relationship parameter for all joins.
  This will ensure that metrics aggregate properly within Looker. By default, Looker will use a many_to_one join relationship for any joins in which a relationship is not defined.
• Do: Define a primary key within each and every view, including derived tables.
  All views, whether from the database directly or derived, should contain a primary key. This primary key should be a unique value, to enable Looker to uniquely identify any given record. This primary key can be a single column or a concatenation of columns ‐ it simply needs to be a unique identifier for the table or derived table.
• Do: Name dimensions, measures, and other LookML objects, using all lowercase letters and underscores for spaces.
  The label parameter can be used for additional formatting of a name field, and can also be used to customize the appearance of view names, Explore names, and Model names.

• Do: Use datagroups to align generation of persistent derived tables (PDTs) and Explore caching with underlying ETL processes. Datagroups can also be used to trigger schedules to ensure that up-to-date data is sent to recipients.

LookML Don’ts

• Don’t: Use the from parameter for renaming views within an Explore.
  Use the view_label parameter instead. For more on the difference between from and view_label, check out our parameters documentation. The from parameter should primarily be used in the following situations:
  • Polymorphic joins (joining the same table multiple times)
  • Self-joins (joining a table to itself)
  • Re-scoping an extended view back to its original view name
• Don’t: Use the words “date” or “time” in a dimension group name.
  Looker appends each timeframe to the end of the dimension group name. This means a dimension group named created_date results in fields called created_date_date, created_date_month, and so on. Simply use created as the dimension group name, because this results in fields named created_date, created_month, and so forth.
• Don’t: Use formatted timestamps within joins.
  Instead, use the raw timeframe option for joining on any date or time fields. This will avoid the inclusion of casting and timezone conversion in join predicates.

About Me:-
I am Om Prakash Singh – Data Analytics Consultant , Looker Consultant , Solution Architect .
I am Highly analytical and process-oriented Data Analyst with in-depth knowledge of database types; research methodologies; and big data capture, manipulation and visualization. Furnish insights, analytics and business intelligence used to advance opportunity identification.

You’ve got data and lots of it. If you’re like most enterprises, you’re struggling to transform massive information into actionable insights for better decision-making and increased business results.
Reach out to us here if you are interested to evaluate if Looker is right for you or any other BI solution.

Ref Link – https://cloud.google.com/looker/docs/best-practices/best-practices-lookml-dos-and-donts