Code Simplification & Idioms

Rules for simplifying code using Python idioms, comprehensions, operators, and eliminating unnecessary complexity

When to check: When refactoring code for clarity or looking to simplify complex patterns

Rules

<!-- rule:255 -->

• Use list comprehensions instead of for-loop-with-append patterns — More concise, readable, and often faster for transforming/filtering iterables into lists

<!-- rule:85 -->

• Omit parameters that match default values in function/constructor calls — Reduces noise, prevents maintenance burden when defaults change, and makes non-default configuration more visible

<!-- rule:166 -->

• Eliminate single-use intermediate variables — reassign or return directly instead of creating _filtered, _copy, etc. — Reduces noise and indirection, making data flow clearer and eliminating unnecessary names that don't add semantic value.

<!-- rule:122 -->

• Flatten nested if statements with no intervening code into if condition1 and condition2: — Reduces nesting depth and improves readability without changing logic

<!-- rule:-1 -->

• Use tuple syntax for isinstance() checks, not | union — tuples are faster at runtime — Runtime performance optimization: tuple syntax avoids the overhead of union type creation

<!-- rule:34 -->

• Link to official provider/project docs instead of duplicating model lists, features, or setup details — prevents stale documentation and reduces maintenance burden — Exhaustive inline lists become outdated quickly; authoritative external sources stay current and reduce maintenance

<!-- rule:519 -->

• Use dict comprehensions instead of empty dict + loop — more concise and idiomatic Python — Reduces boilerplate, improves readability, and signals intent more clearly for simple mappings and filtered sequences

<!-- rule:1001 -->

• Define TypeAdapter instances at module level as constants — avoids repeated initialization overhead — Creating TypeAdapters repeatedly inside functions or loops wastes CPU cycles on redundant schema construction that only needs to happen once.

<!-- rule:330 -->

• Use any() instead of for-loops with boolean flags when checking if any element matches a condition — More concise and Pythonic; eliminates manual flag management and break statements, reducing potential for logic errors

<!-- rule:677 -->

• Use @cached_property for expensive computed attributes — defers computation until first access and caches the result — Improves startup performance by avoiding unnecessary computation and reduces memory overhead when attributes may not be used

<!-- rule:3 -->

• Use x or default for fallback values instead of verbose if-else blocks — more concise and idiomatic — This pattern is shorter and clearer for typical fallback logic, but avoid it when falsy values (0, '', [], None) are semantically valid and shouldn't trigger the default

<!-- rule:661 -->

• Remove redundant null/None checks for guaranteed-present values — simplifies code and makes type invariants clearer — Unnecessary defensive checks obscure actual invariants, add maintenance burden, and suggest false uncertainty about what the type system already guarantees