Lesson 02

Nil boundaries and defaults

Normalize nil at the boundary so the rest of the code can distinguish missing data from empty values.

nil
defaults
boundaries

Good Code

src/review_options.lua

local function normalize_options(options)
  options = options or {}

  -- Defaults are chosen once before the review job runs.
  return {
    limit = options.limit or 20,
    include_archived = options.include_archived == true,
  }
end

Bad Code

review_options.lua

local function fetch_reviews(options)
  -- Every read repeats a nil decision with slightly different rules.
  local limit = options and options.limit or 20
  local archived = options and options.include_archived

  return query_reviews(limit, archived)
end

Review Notes

What to review

Good Code

The good version turns optional input into one normalized table. Later code can rely on limit and include_archived having predictable types.

Bad Code

The bad version repeats nil checks inside the workflow. Each line can drift into a different default rule, especially when booleans are involved.

Takeaways

Lua code should choose defaults at input boundaries instead of scattering nil checks through business logic.