Tiger Style: Coding philosophy (2024)

Function Length & Code Structure

• The strongest debate centers on “limit functions to ~70 lines.”
• Critics argue line-count rules are superficial: complexity, state management, and domain matter far more.
  • Overzealous application (often by juniors or enforced by linters) can fragment sequential processes into many one-use helpers scattered across files, increasing cognitive load and debugging difficulty.
  • Domains like interpreters, video game state machines, transaction pipelines, and “long script” orchestration often benefit from longer, linear functions that show the full flow.
• Supporters see the limit as a heuristic, not a hard rule.
  • Most long functions in real codebases are “god functions” with tangled control flow and state; breaking them into smaller, well‑named helpers improves comprehension, testability, and maintainability.
  • Line count is treated as a smell or “tripwire” that prompts review, not an absolute constraint.
• There is broad agreement that:
  • Splitting solely to satisfy metrics is harmful.
  • Isolating state, using pure functions where possible, and keeping orchestration readable are more important than any specific number.

Technical Debt, Performance, and “Do It Right First Time”

• “Zero technical debt” and “do it right the first time” are widely questioned.
  • Many see them as unrealistic or “privileged,” ignoring uncertainty, evolving requirements, and time/money constraints, especially in startups.
  • A lot of debt comes from changed product requirements, not laziness. Over‑engineering early can itself become severe debt.
• Others counter that “no technical debt” means “no deliberate corner‑cutting,” not perfection, and that systematically avoiding shortcuts often pays off within months.
• A more accepted stance: continuously manage and reduce debt, favor designs that avoid one‑way doors, and accept that some debt is inevitable.

Other Guidelines: Memory, Recursion, Line Length

• “Allocate all memory at startup” is seen as appropriate for long‑running, high‑reliability services but wasteful or harmful for general applications; dynamic allocation complexity vs. flexibility is debated.
• “Avoid recursion if possible” is criticized as imperative‑centric; in languages with tail calls or in naturally recursive domains (parsers, trees, divide‑and‑conquer), recursion is considered idiomatic.
• Line length limits (e.g., 100 chars) have mixed reception: some prioritize avoiding horizontal scrolling, others prefer wrapping and worry about excessive vertical space and over‑formatted comments.

Context, Safety-Critical Style, and Audience

• Several commenters note the philosophy resembles NASA/MISRA-style safety rules, appropriate for financial transaction systems or safety‑critical software, but too heavy for many commercial domains.
• Some see it as Clean Code‑like idealism or early‑career dogma; others as a solid baseline for training juniors.
• Multiple people stress the need for concrete examples and explicit framing as guidelines, not absolutes, to prevent cargo‑cult adoption.