max_code_lines

Rule: max_code_lines


max_code_lines details
This rule enforces a maximum line count for dbt code objects, helping to maintain code readability and encourage modular design. Objects with empty code will also be flagged by this rule.

Configuration

  • type: Must be max_code_lines.
  • max_lines: (optional) The maximum number of lines allowed for the code. Defaults to 150.
  • applies_to: (optional) List of dbt object types to include.
    • Default: ["models", "snapshots", "macros"]
    • Options: models, snapshots, macros
Common Rule Config
  • name: Human-readable name of the rule.
  • severity: "error" (fail) or "warning" (warn only).
    • (optional, defaults to "error" if not specified)
  • description: Human-readable explanation of the rule.
  • includes: List of patterns to explicitly include for this rule.
      Paths are relative to the original_file_path from the manifest.
      Pattern syntax:
    • * matches any characters except / (within a single directory)
    • ** matches any characters including / (across directories)
    • ^ at the start anchors to the beginning of the path
    • $ at the end anchors to the end of the path
    • Without anchors, pattern matches if it appears anywhere in the path (contains)
        Examples:     ^models/staging/ - paths starting with models/staging/     orders - paths containing orders anywhere     .sql$ - paths ending with .sql     ^models/*.sql$ - SQL files directly in models/ folder     ^models/**/*.sql$ - SQL files in any subfolder of models/
  • excludes: List of patterns to explicitly exclude from this rule.
      Uses the same pattern syntax as includes.
      Examples:     ^models/legacy/ - exclude legacy models folder     _deprecated - exclude paths containing _deprecated     ^tests/ - exclude test files
  • model_materializations: Filter models by materialization type. Only applies when applies_to includes models.
      (optional, if not specified all materializations are included)
      Built-in types: table, view, incremental, ephemeral, materialized_view. Custom materializations are also supported.
      Example: ["table", "incremental"]

Example Config

manifest_tests:
  - name: "models_max_100_lines"
    type: "max_code_lines"
    max_lines: 100
    description: "Models should not exceed 100 lines of code."
    # severity: "warning"  (optional)
    # applies_to: ['models', 'snapshots'] (optional)
    # includes: ["path/to/include/*"]
    # excludes: ["path/to/exclude/*"]
[[manifest_tests]]
name = "models_max_100_lines"
type = "max_code_lines"
max_lines = 100
description = "Models should not exceed 100 lines of code."
# severity = "warning"  # (optional)
# applies_to = ["models", "snapshots"]  # (optional)
# includes = ["path/to/include/*"]
# excludes = ["path/to/exclude/*"]
[[tool.dbtective.manifest_tests]]
name = "models_max_100_lines"
type = "max_code_lines"
max_lines = 100
description = "Models should not exceed 100 lines of code."
# severity = "warning"  # (optional)
# applies_to = ["models", "snapshots"]  # (optional)
# includes = ["path/to/include/*"]
# excludes = ["path/to/exclude/*"]
Relevant dbt code
-- models/short_model.sql (PASS)
SELECT
    id,
    name
FROM users

-- models/very_long_model.sql (FAIL - exceeds max_lines)
SELECT
    id,
    name,
    email,
    ...
    -- 101+ lines of SQL
    ...
FROM users

-- models/empty_model.sql (FAIL - empty code)
-- No content
Use cases
  • Enforce code modularity by limiting file size
  • Prevent overly complex transformations in single files
  • Encourage breaking down large models into smaller, reusable CTEs or models
  • Maintain consistent code readability across the project
  • Catch accidentally empty SQL files