clean-code-tools 1.0.1

package/data/clean-code-patterns.jsonl

@@ -0,0 +1,264 @@
+{"aliases": ["clean code: express requirements precisely", "clean code express requirements precisely", "clean code", "requirements precisely", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-001 Clean Code: Express Requirements Precisely\nTopic: Clean Code\nAliases: clean code: express requirements precisely, clean code express requirements precisely, clean code, requirements precisely, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to clean code: express requirements precisely: Make business rules executable and explicit instead of leaving them as vague comments or tribal knowledge. Search terms that should match this issue include clean code: express requirements precisely, clean code express requirements precisely, clean code, requirements precisely, code smell.\nUse when: Use this pattern when planning or reviewing code where make business rules executable and explicit instead of leaving them as vague comments or tribal knowledge. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\ntype TransferRequest = { amount: Money; from: Account; to: Account };\n\nfunction validateTransfer(request: TransferRequest): void {\n  if (!request.from.canDebit(request.amount)) {\n    throw new InsufficientFundsError(request.from.id);\n  }\n}\nGood Python:\n@dataclass(frozen=True)\nclass TransferRequest:\n    amount: Money\n    from_account: Account\n    to_account: Account\n\n\ndef validate_transfer(request: TransferRequest) -> None:\n    if not request.from_account.can_debit(request.amount):\n        raise InsufficientFundsError(request.from_account.id)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag comments that describe a business rule not represented by a named function, type, or test.\nLintability: high", "embedding_text": "Clean code pattern CC-001: Clean Code: Express Requirements Precisely. Topic: Clean Code. Rule family: clean_code. Aliases and smell terms: clean code: express requirements precisely, clean code express requirements precisely, clean code, requirements precisely, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to clean code: express requirements precisely: Make business rules executable and explicit instead of leaving them as vague comments or tribal knowledge. Search terms that should match this issue include clean code: express requirements precisely, clean code express requirements precisely, clean code, requirements precisely, code smell. Use when: Use this pattern when planning or reviewing code where make business rules executable and explicit instead of leaving them as vague comments or tribal knowledge. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Flag comments that describe a business rule not represented by a named function, type, or test.. Good TypeScript example: type TransferRequest = { amount: Money; from: Account; to: Account };\n\nfunction validateTransfer(request: TransferRequest): void {\n  if (!request.from.canDebit(request.amount)) {\n    throw new InsufficientFundsError(request.from.id);\n  }\n} Good Python example: @dataclass(frozen=True)\nclass TransferRequest:\n    amount: Money\n    from_account: Account\n    to_account: Account\n\n\ndef validate_transfer(request: TransferRequest) -> None:\n    if not request.from_account.can_debit(request.amount):\n        raise InsufficientFundsError(request.from_account.id) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "@dataclass(frozen=True)\nclass TransferRequest:\n    amount: Money\n    from_account: Account\n    to_account: Account\n\n\ndef validate_transfer(request: TransferRequest) -> None:\n    if not request.from_account.can_debit(request.amount):\n        raise InsufficientFundsError(request.from_account.id)", "typescript": "type TransferRequest = { amount: Money; from: Account; to: Account };\n\nfunction validateTransfer(request: TransferRequest): void {\n  if (!request.from.canDebit(request.amount)) {\n    throw new InsufficientFundsError(request.from.id);\n  }\n}"}, "id": "CC-001", "lint_candidates": ["Flag comments that describe a business rule not represented by a named function, type, or test."], "lintability": "high", "problem": "Code has a clean-code risk related to clean code: express requirements precisely: Make business rules executable and explicit instead of leaving them as vague comments or tribal knowledge. Search terms that should match this issue include clean code: express requirements precisely, clean code express requirements precisely, clean code, requirements precisely, code smell.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Clean Code: Express Requirements Precisely", "topic": "Clean Code", "use_when": "Use this pattern when planning or reviewing code where make business rules executable and explicit instead of leaving them as vague comments or tribal knowledge. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["there will be code: keep details executable", "there will be code keep details executable", "there will", "details executable", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-002 There Will Be Code: Keep Details Executable\nTopic: Clean Code\nAliases: there will be code: keep details executable, there will be code keep details executable, there will, details executable, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to there will be code: keep details executable: Represent detailed requirements in code and tests, not only in planning documents. Search terms that should match this issue include there will be code: keep details executable, there will be code keep details executable, there will, details executable, clean code.\nUse when: Use this pattern when planning or reviewing code where represent detailed requirements in code and tests, not only in planning documents. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst MINIMUM_WITHDRAWAL = money(\"10.00\");\n\nfunction canWithdraw(amount: Money): boolean {\n  return amount.greaterThanOrEqual(MINIMUM_WITHDRAWAL);\n}\nGood Python:\nMINIMUM_WITHDRAWAL = Money(\"10.00\")\n\n\ndef can_withdraw(amount: Money) -> bool:\n    return amount >= MINIMUM_WITHDRAWAL\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag hard-coded policy literals that are not named constants.\nLintability: high", "embedding_text": "Clean code pattern CC-002: There Will Be Code: Keep Details Executable. Topic: Clean Code. Rule family: clean_code. Aliases and smell terms: there will be code: keep details executable, there will be code keep details executable, there will, details executable, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to there will be code: keep details executable: Represent detailed requirements in code and tests, not only in planning documents. Search terms that should match this issue include there will be code: keep details executable, there will be code keep details executable, there will, details executable, clean code. Use when: Use this pattern when planning or reviewing code where represent detailed requirements in code and tests, not only in planning documents. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Flag hard-coded policy literals that are not named constants.. Good TypeScript example: const MINIMUM_WITHDRAWAL = money(\"10.00\");\n\nfunction canWithdraw(amount: Money): boolean {\n  return amount.greaterThanOrEqual(MINIMUM_WITHDRAWAL);\n} Good Python example: MINIMUM_WITHDRAWAL = Money(\"10.00\")\n\n\ndef can_withdraw(amount: Money) -> bool:\n    return amount >= MINIMUM_WITHDRAWAL Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "MINIMUM_WITHDRAWAL = Money(\"10.00\")\n\n\ndef can_withdraw(amount: Money) -> bool:\n    return amount >= MINIMUM_WITHDRAWAL", "typescript": "const MINIMUM_WITHDRAWAL = money(\"10.00\");\n\nfunction canWithdraw(amount: Money): boolean {\n  return amount.greaterThanOrEqual(MINIMUM_WITHDRAWAL);\n}"}, "id": "CC-002", "lint_candidates": ["Flag hard-coded policy literals that are not named constants."], "lintability": "high", "problem": "Code has a clean-code risk related to there will be code: keep details executable: Represent detailed requirements in code and tests, not only in planning documents. Search terms that should match this issue include there will be code: keep details executable, there will be code keep details executable, there will, details executable, clean code.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "There Will Be Code: Keep Details Executable", "topic": "Clean Code", "use_when": "Use this pattern when planning or reviewing code where represent detailed requirements in code and tests, not only in planning documents. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["bad code: stop adding to the mess", "bad code stop adding to the mess", "bad code", "the mess", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-003 Bad Code: Stop Adding To The Mess\nTopic: Clean Code\nAliases: bad code: stop adding to the mess, bad code stop adding to the mess, bad code, the mess, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to bad code: stop adding to the mess: When code is already tangled, add a named seam before changing behavior. Search terms that should match this issue include bad code: stop adding to the mess, bad code stop adding to the mess, bad code, the mess, clean code.\nUse when: Use this pattern when planning or reviewing code where when code is already tangled, add a named seam before changing behavior. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nasync function retryFailedPayment(paymentId: string): Promise<void> {\n  const payment = await paymentRepository.get(paymentId);\n  await retryPayment(payment);\n}\nGood Python:\ndef retry_failed_payment(payment_id: str) -> None:\n    payment = payment_repository.get(payment_id)\n    retry_payment(payment)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag large handlers that mix lookup, validation, retry policy, and notification logic.\nLintability: high", "embedding_text": "Clean code pattern CC-003: Bad Code: Stop Adding To The Mess. Topic: Clean Code. Rule family: clean_code. Aliases and smell terms: bad code: stop adding to the mess, bad code stop adding to the mess, bad code, the mess, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to bad code: stop adding to the mess: When code is already tangled, add a named seam before changing behavior. Search terms that should match this issue include bad code: stop adding to the mess, bad code stop adding to the mess, bad code, the mess, clean code. Use when: Use this pattern when planning or reviewing code where when code is already tangled, add a named seam before changing behavior. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Flag large handlers that mix lookup, validation, retry policy, and notification logic.. Good TypeScript example: async function retryFailedPayment(paymentId: string): Promise<void> {\n  const payment = await paymentRepository.get(paymentId);\n  await retryPayment(payment);\n} Good Python example: def retry_failed_payment(payment_id: str) -> None:\n    payment = payment_repository.get(payment_id)\n    retry_payment(payment) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def retry_failed_payment(payment_id: str) -> None:\n    payment = payment_repository.get(payment_id)\n    retry_payment(payment)", "typescript": "async function retryFailedPayment(paymentId: string): Promise<void> {\n  const payment = await paymentRepository.get(paymentId);\n  await retryPayment(payment);\n}"}, "id": "CC-003", "lint_candidates": ["Flag large handlers that mix lookup, validation, retry policy, and notification logic."], "lintability": "high", "problem": "Code has a clean-code risk related to bad code: stop adding to the mess: When code is already tangled, add a named seam before changing behavior. Search terms that should match this issue include bad code: stop adding to the mess, bad code stop adding to the mess, bad code, the mess, clean code.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Bad Code: Stop Adding To The Mess", "topic": "Clean Code", "use_when": "Use this pattern when planning or reviewing code where when code is already tangled, add a named seam before changing behavior. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["total cost: reduce change amplification", "total cost reduce change amplification", "total cost", "change amplification", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-004 Total Cost: Reduce Change Amplification\nTopic: Clean Code\nAliases: total cost: reduce change amplification, total cost reduce change amplification, total cost, change amplification, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to total cost: reduce change amplification: Centralize a rule so one policy change does not require edits across many modules. Search terms that should match this issue include total cost: reduce change amplification, total cost reduce change amplification, total cost, change amplification, clean code.\nUse when: Use this pattern when planning or reviewing code where centralize a rule so one policy change does not require edits across many modules. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nfunction isOrderEditable(order: Order): boolean {\n  return order.status === \"draft\" || order.status === \"payment_failed\";\n}\nGood Python:\ndef is_order_editable(order: Order) -> bool:\n    return order.status in {\"draft\", \"payment_failed\"}\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Detect duplicated condition expressions across files.\nLintability: medium", "embedding_text": "Clean code pattern CC-004: Total Cost: Reduce Change Amplification. Topic: Clean Code. Rule family: clean_code. Aliases and smell terms: total cost: reduce change amplification, total cost reduce change amplification, total cost, change amplification, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to total cost: reduce change amplification: Centralize a rule so one policy change does not require edits across many modules. Search terms that should match this issue include total cost: reduce change amplification, total cost reduce change amplification, total cost, change amplification, clean code. Use when: Use this pattern when planning or reviewing code where centralize a rule so one policy change does not require edits across many modules. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Detect duplicated condition expressions across files.. Good TypeScript example: function isOrderEditable(order: Order): boolean {\n  return order.status === \"draft\" || order.status === \"payment_failed\";\n} Good Python example: def is_order_editable(order: Order) -> bool:\n    return order.status in {\"draft\", \"payment_failed\"} Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def is_order_editable(order: Order) -> bool:\n    return order.status in {\"draft\", \"payment_failed\"}", "typescript": "function isOrderEditable(order: Order): boolean {\n  return order.status === \"draft\" || order.status === \"payment_failed\";\n}"}, "id": "CC-004", "lint_candidates": ["Detect duplicated condition expressions across files."], "lintability": "medium", "problem": "Code has a clean-code risk related to total cost: reduce change amplification: Centralize a rule so one policy change does not require edits across many modules. Search terms that should match this issue include total cost: reduce change amplification, total cost reduce change amplification, total cost, change amplification, clean code.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Total Cost: Reduce Change Amplification", "topic": "Clean Code", "use_when": "Use this pattern when planning or reviewing code where centralize a rule so one policy change does not require edits across many modules. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["grand redesign: improve incrementally", "grand redesign improve incrementally", "grand redesign", "improve incrementally", "simple design", "emergent design", "expressive code", "minimal design", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-005 Grand Redesign: Improve Incrementally\nTopic: Clean Code\nAliases: grand redesign: improve incrementally, grand redesign improve incrementally, grand redesign, improve incrementally, simple design, emergent design, expressive code, minimal design, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to grand redesign: improve incrementally: Prefer small replacement steps around protected behavior over a risky rewrite. Search terms that should match this issue include grand redesign: improve incrementally, grand redesign improve incrementally, grand redesign, improve incrementally, simple design.\nUse when: Use this pattern when planning or reviewing code where prefer small replacement steps around protected behavior over a risky rewrite. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nfunction calculateInvoiceTotal(invoice: Invoice): Money {\n  return invoiceTotalCalculator.calculate(invoice);\n}\nGood Python:\ndef calculate_invoice_total(invoice: Invoice) -> Money:\n    return invoice_total_calculator.calculate(invoice)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: No direct lint rule; require characterization tests before replacing legacy calculations.\nLintability: review_only", "embedding_text": "Clean code pattern CC-005: Grand Redesign: Improve Incrementally. Topic: Clean Code. Rule family: design. Aliases and smell terms: grand redesign: improve incrementally, grand redesign improve incrementally, grand redesign, improve incrementally, simple design, emergent design, expressive code, minimal design, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to grand redesign: improve incrementally: Prefer small replacement steps around protected behavior over a risky rewrite. Search terms that should match this issue include grand redesign: improve incrementally, grand redesign improve incrementally, grand redesign, improve incrementally, simple design. Use when: Use this pattern when planning or reviewing code where prefer small replacement steps around protected behavior over a risky rewrite. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: No direct lint rule; require characterization tests before replacing legacy calculations.. Good TypeScript example: function calculateInvoiceTotal(invoice: Invoice): Money {\n  return invoiceTotalCalculator.calculate(invoice);\n} Good Python example: def calculate_invoice_total(invoice: Invoice) -> Money:\n    return invoice_total_calculator.calculate(invoice) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def calculate_invoice_total(invoice: Invoice) -> Money:\n    return invoice_total_calculator.calculate(invoice)", "typescript": "function calculateInvoiceTotal(invoice: Invoice): Money {\n  return invoiceTotalCalculator.calculate(invoice);\n}"}, "id": "CC-005", "lint_candidates": ["No direct lint rule; require characterization tests before replacing legacy calculations."], "lintability": "review_only", "problem": "Code has a clean-code risk related to grand redesign: improve incrementally: Prefer small replacement steps around protected behavior over a risky rewrite. Search terms that should match this issue include grand redesign: improve incrementally, grand redesign improve incrementally, grand redesign, improve incrementally, simple design.", "rule_family": "design", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Grand Redesign: Improve Incrementally", "topic": "Clean Code", "use_when": "Use this pattern when planning or reviewing code where prefer small replacement steps around protected behavior over a risky rewrite. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["attitude: own the code you touch", "attitude own the code you touch", "attitude own", "you touch", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-006 Attitude: Own The Code You Touch\nTopic: Clean Code\nAliases: attitude: own the code you touch, attitude own the code you touch, attitude own, you touch, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to attitude: own the code you touch: Leave touched code slightly clearer by naming the rule you had to understand. Search terms that should match this issue include attitude: own the code you touch, attitude own the code you touch, attitude own, you touch, clean code.\nUse when: Use this pattern when planning or reviewing code where leave touched code slightly clearer by naming the rule you had to understand. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst requiresManualApproval = transfer.amount.isGreaterThan(DAILY_REVIEW_LIMIT);\n\nif (requiresManualApproval) {\n  queueManualApproval(transfer);\n}\nGood Python:\nrequires_manual_approval = transfer.amount > DAILY_REVIEW_LIMIT\n\nif requires_manual_approval:\n    queue_manual_approval(transfer)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag complex inline conditions in changed lines.\nLintability: review_only", "embedding_text": "Clean code pattern CC-006: Attitude: Own The Code You Touch. Topic: Clean Code. Rule family: clean_code. Aliases and smell terms: attitude: own the code you touch, attitude own the code you touch, attitude own, you touch, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to attitude: own the code you touch: Leave touched code slightly clearer by naming the rule you had to understand. Search terms that should match this issue include attitude: own the code you touch, attitude own the code you touch, attitude own, you touch, clean code. Use when: Use this pattern when planning or reviewing code where leave touched code slightly clearer by naming the rule you had to understand. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Flag complex inline conditions in changed lines.. Good TypeScript example: const requiresManualApproval = transfer.amount.isGreaterThan(DAILY_REVIEW_LIMIT);\n\nif (requiresManualApproval) {\n  queueManualApproval(transfer);\n} Good Python example: requires_manual_approval = transfer.amount > DAILY_REVIEW_LIMIT\n\nif requires_manual_approval:\n    queue_manual_approval(transfer) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "requires_manual_approval = transfer.amount > DAILY_REVIEW_LIMIT\n\nif requires_manual_approval:\n    queue_manual_approval(transfer)", "typescript": "const requiresManualApproval = transfer.amount.isGreaterThan(DAILY_REVIEW_LIMIT);\n\nif (requiresManualApproval) {\n  queueManualApproval(transfer);\n}"}, "id": "CC-006", "lint_candidates": ["Flag complex inline conditions in changed lines."], "lintability": "review_only", "problem": "Code has a clean-code risk related to attitude: own the code you touch: Leave touched code slightly clearer by naming the rule you had to understand. Search terms that should match this issue include attitude: own the code you touch, attitude own the code you touch, attitude own, you touch, clean code.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Attitude: Own The Code You Touch", "topic": "Clean Code", "use_when": "Use this pattern when planning or reviewing code where leave touched code slightly clearer by naming the rule you had to understand. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["primal conundrum: clean is fast", "primal conundrum clean is fast", "primal conundrum", "is fast", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-007 Primal Conundrum: Clean Is Fast\nTopic: Clean Code\nAliases: primal conundrum: clean is fast, primal conundrum clean is fast, primal conundrum, is fast, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to primal conundrum: clean is fast: Choose a clear implementation that keeps future changes cheap instead of hiding shortcuts in rushed code. Search terms that should match this issue include primal conundrum: clean is fast, primal conundrum clean is fast, primal conundrum, is fast, clean code.\nUse when: Use this pattern when planning or reviewing code where choose a clear implementation that keeps future changes cheap instead of hiding shortcuts in rushed code. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nfunction shippingMethodFor(order: Order): ShippingMethod {\n  if (order.requiresColdChain) return ShippingMethod.Refrigerated;\n  return ShippingMethod.Standard;\n}\nGood Python:\ndef shipping_method_for(order: Order) -> ShippingMethod:\n    if order.requires_cold_chain:\n        return ShippingMethod.REFRIGERATED\n    return ShippingMethod.STANDARD\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag nested ternaries used for business policy.\nLintability: high", "embedding_text": "Clean code pattern CC-007: Primal Conundrum: Clean Is Fast. Topic: Clean Code. Rule family: clean_code. Aliases and smell terms: primal conundrum: clean is fast, primal conundrum clean is fast, primal conundrum, is fast, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to primal conundrum: clean is fast: Choose a clear implementation that keeps future changes cheap instead of hiding shortcuts in rushed code. Search terms that should match this issue include primal conundrum: clean is fast, primal conundrum clean is fast, primal conundrum, is fast, clean code. Use when: Use this pattern when planning or reviewing code where choose a clear implementation that keeps future changes cheap instead of hiding shortcuts in rushed code. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Flag nested ternaries used for business policy.. Good TypeScript example: function shippingMethodFor(order: Order): ShippingMethod {\n  if (order.requiresColdChain) return ShippingMethod.Refrigerated;\n  return ShippingMethod.Standard;\n} Good Python example: def shipping_method_for(order: Order) -> ShippingMethod:\n    if order.requires_cold_chain:\n        return ShippingMethod.REFRIGERATED\n    return ShippingMethod.STANDARD Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def shipping_method_for(order: Order) -> ShippingMethod:\n    if order.requires_cold_chain:\n        return ShippingMethod.REFRIGERATED\n    return ShippingMethod.STANDARD", "typescript": "function shippingMethodFor(order: Order): ShippingMethod {\n  if (order.requiresColdChain) return ShippingMethod.Refrigerated;\n  return ShippingMethod.Standard;\n}"}, "id": "CC-007", "lint_candidates": ["Flag nested ternaries used for business policy."], "lintability": "high", "problem": "Code has a clean-code risk related to primal conundrum: clean is fast: Choose a clear implementation that keeps future changes cheap instead of hiding shortcuts in rushed code. Search terms that should match this issue include primal conundrum: clean is fast, primal conundrum clean is fast, primal conundrum, is fast, clean code.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Primal Conundrum: Clean Is Fast", "topic": "Clean Code", "use_when": "Use this pattern when planning or reviewing code where choose a clear implementation that keeps future changes cheap instead of hiding shortcuts in rushed code. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["art of clean code: practice refactoring", "art of clean code practice refactoring", "art of", "practice refactoring", "refactoring", "successive refinement", "incremental change", "safe change", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-008 Art Of Clean Code: Practice Refactoring\nTopic: Clean Code\nAliases: art of clean code: practice refactoring, art of clean code practice refactoring, art of, practice refactoring, refactoring, successive refinement, incremental change, safe change, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to art of clean code: practice refactoring: Make code easier to read through repeated small improvements, not one-time cleanup campaigns. Search terms that should match this issue include art of clean code: practice refactoring, art of clean code practice refactoring, art of, practice refactoring, refactoring.\nUse when: Use this pattern when planning or reviewing code where make code easier to read through repeated small improvements, not one-time cleanup campaigns. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst paidOrders = orders.filter(isPaidOrder);\nconst receipts = paidOrders.map(createReceipt);\nGood Python:\npaid_orders = [order for order in orders if is_paid_order(order)]\nreceipts = [create_receipt(order) for order in paid_orders]\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag chained transformations longer than a configurable threshold.\nLintability: review_only", "embedding_text": "Clean code pattern CC-008: Art Of Clean Code: Practice Refactoring. Topic: Clean Code. Rule family: refactoring. Aliases and smell terms: art of clean code: practice refactoring, art of clean code practice refactoring, art of, practice refactoring, refactoring, successive refinement, incremental change, safe change, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to art of clean code: practice refactoring: Make code easier to read through repeated small improvements, not one-time cleanup campaigns. Search terms that should match this issue include art of clean code: practice refactoring, art of clean code practice refactoring, art of, practice refactoring, refactoring. Use when: Use this pattern when planning or reviewing code where make code easier to read through repeated small improvements, not one-time cleanup campaigns. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Flag chained transformations longer than a configurable threshold.. Good TypeScript example: const paidOrders = orders.filter(isPaidOrder);\nconst receipts = paidOrders.map(createReceipt); Good Python example: paid_orders = [order for order in orders if is_paid_order(order)]\nreceipts = [create_receipt(order) for order in paid_orders] Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "paid_orders = [order for order in orders if is_paid_order(order)]\nreceipts = [create_receipt(order) for order in paid_orders]", "typescript": "const paidOrders = orders.filter(isPaidOrder);\nconst receipts = paidOrders.map(createReceipt);"}, "id": "CC-008", "lint_candidates": ["Flag chained transformations longer than a configurable threshold."], "lintability": "review_only", "problem": "Code has a clean-code risk related to art of clean code: practice refactoring: Make code easier to read through repeated small improvements, not one-time cleanup campaigns. Search terms that should match this issue include art of clean code: practice refactoring, art of clean code practice refactoring, art of, practice refactoring, refactoring.", "rule_family": "refactoring", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Art Of Clean Code: Practice Refactoring", "topic": "Clean Code", "use_when": "Use this pattern when planning or reviewing code where make code easier to read through repeated small improvements, not one-time cleanup campaigns. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["what is clean code: make intent obvious", "what is clean code make intent obvious", "what is", "intent obvious", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-009 What Is Clean Code: Make Intent Obvious\nTopic: Clean Code\nAliases: what is clean code: make intent obvious, what is clean code make intent obvious, what is, intent obvious, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to what is clean code: make intent obvious: Clean code exposes its purpose through structure, names, and tests. Search terms that should match this issue include what is clean code: make intent obvious, what is clean code make intent obvious, what is, intent obvious, clean code.\nUse when: Use this pattern when planning or reviewing code where clean code exposes its purpose through structure, names, and tests. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nfunction suspendDormantAccounts(accounts: Account[], now: Date): Account[] {\n  return accounts.filter((account) => isDormant(account, now)).map(suspendAccount);\n}\nGood Python:\ndef suspend_dormant_accounts(accounts: list[Account], now: datetime) -> list[Account]:\n    return [suspend_account(account) for account in accounts if is_dormant(account, now)]\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag functions whose name is less specific than the domain operations inside.\nLintability: high", "embedding_text": "Clean code pattern CC-009: What Is Clean Code: Make Intent Obvious. Topic: Clean Code. Rule family: clean_code. Aliases and smell terms: what is clean code: make intent obvious, what is clean code make intent obvious, what is, intent obvious, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to what is clean code: make intent obvious: Clean code exposes its purpose through structure, names, and tests. Search terms that should match this issue include what is clean code: make intent obvious, what is clean code make intent obvious, what is, intent obvious, clean code. Use when: Use this pattern when planning or reviewing code where clean code exposes its purpose through structure, names, and tests. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Flag functions whose name is less specific than the domain operations inside.. Good TypeScript example: function suspendDormantAccounts(accounts: Account[], now: Date): Account[] {\n  return accounts.filter((account) => isDormant(account, now)).map(suspendAccount);\n} Good Python example: def suspend_dormant_accounts(accounts: list[Account], now: datetime) -> list[Account]:\n    return [suspend_account(account) for account in accounts if is_dormant(account, now)] Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def suspend_dormant_accounts(accounts: list[Account], now: datetime) -> list[Account]:\n    return [suspend_account(account) for account in accounts if is_dormant(account, now)]", "typescript": "function suspendDormantAccounts(accounts: Account[], now: Date): Account[] {\n  return accounts.filter((account) => isDormant(account, now)).map(suspendAccount);\n}"}, "id": "CC-009", "lint_candidates": ["Flag functions whose name is less specific than the domain operations inside."], "lintability": "high", "problem": "Code has a clean-code risk related to what is clean code: make intent obvious: Clean code exposes its purpose through structure, names, and tests. Search terms that should match this issue include what is clean code: make intent obvious, what is clean code make intent obvious, what is, intent obvious, clean code.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "What Is Clean Code: Make Intent Obvious", "topic": "Clean Code", "use_when": "Use this pattern when planning or reviewing code where clean code exposes its purpose through structure, names, and tests. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["schools of thought: prefer team consistency", "schools of thought prefer team consistency", "schools of", "team consistency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-010 Schools Of Thought: Prefer Team Consistency\nTopic: Clean Code\nAliases: schools of thought: prefer team consistency, schools of thought prefer team consistency, schools of, team consistency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to schools of thought: prefer team consistency: Apply a consistent local style so readers do not have to switch conventions within the same codebase. Search terms that should match this issue include schools of thought: prefer team consistency, schools of thought prefer team consistency, schools of, team consistency, clean code.\nUse when: Use this pattern when planning or reviewing code where apply a consistent local style so readers do not have to switch conventions within the same codebase. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nfunction formatCustomerName(customer: Customer): string {\n  return `${customer.givenName} ${customer.familyName}`.trim();\n}\nGood Python:\ndef format_customer_name(customer: Customer) -> str:\n    return f\"{customer.given_name} {customer.family_name}\".strip()\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use formatter and naming rules consistently per language.\nLintability: review_only", "embedding_text": "Clean code pattern CC-010: Schools Of Thought: Prefer Team Consistency. Topic: Clean Code. Rule family: clean_code. Aliases and smell terms: schools of thought: prefer team consistency, schools of thought prefer team consistency, schools of, team consistency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to schools of thought: prefer team consistency: Apply a consistent local style so readers do not have to switch conventions within the same codebase. Search terms that should match this issue include schools of thought: prefer team consistency, schools of thought prefer team consistency, schools of, team consistency, clean code. Use when: Use this pattern when planning or reviewing code where apply a consistent local style so readers do not have to switch conventions within the same codebase. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use formatter and naming rules consistently per language.. Good TypeScript example: function formatCustomerName(customer: Customer): string {\n  return `${customer.givenName} ${customer.familyName}`.trim();\n} Good Python example: def format_customer_name(customer: Customer) -> str:\n    return f\"{customer.given_name} {customer.family_name}\".strip() Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def format_customer_name(customer: Customer) -> str:\n    return f\"{customer.given_name} {customer.family_name}\".strip()", "typescript": "function formatCustomerName(customer: Customer): string {\n  return `${customer.givenName} ${customer.familyName}`.trim();\n}"}, "id": "CC-010", "lint_candidates": ["Use formatter and naming rules consistently per language."], "lintability": "review_only", "problem": "Code has a clean-code risk related to schools of thought: prefer team consistency: Apply a consistent local style so readers do not have to switch conventions within the same codebase. Search terms that should match this issue include schools of thought: prefer team consistency, schools of thought prefer team consistency, schools of, team consistency, clean code.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Schools Of Thought: Prefer Team Consistency", "topic": "Clean Code", "use_when": "Use this pattern when planning or reviewing code where apply a consistent local style so readers do not have to switch conventions within the same codebase. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["we are authors: optimize for readers", "we are authors optimize for readers", "we are", "for readers", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-011 We Are Authors: Optimize For Readers\nTopic: Clean Code\nAliases: we are authors: optimize for readers, we are authors optimize for readers, we are, for readers, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to we are authors: optimize for readers: Code is read more often than it is written, so make the call site read naturally. Search terms that should match this issue include we are authors: optimize for readers, we are authors optimize for readers, we are, for readers, clean code.\nUse when: Use this pattern when planning or reviewing code where code is read more often than it is written, so make the call site read naturally. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nif (customerCanUseCoupon(customer, coupon)) {\n  applyCoupon(cart, coupon);\n}\nGood Python:\nif customer_can_use_coupon(customer, coupon):\n    apply_coupon(cart, coupon)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag predicate functions that do not start with a question-like prefix.\nLintability: high", "embedding_text": "Clean code pattern CC-011: We Are Authors: Optimize For Readers. Topic: Clean Code. Rule family: clean_code. Aliases and smell terms: we are authors: optimize for readers, we are authors optimize for readers, we are, for readers, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to we are authors: optimize for readers: Code is read more often than it is written, so make the call site read naturally. Search terms that should match this issue include we are authors: optimize for readers, we are authors optimize for readers, we are, for readers, clean code. Use when: Use this pattern when planning or reviewing code where code is read more often than it is written, so make the call site read naturally. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Flag predicate functions that do not start with a question-like prefix.. Good TypeScript example: if (customerCanUseCoupon(customer, coupon)) {\n  applyCoupon(cart, coupon);\n} Good Python example: if customer_can_use_coupon(customer, coupon):\n    apply_coupon(cart, coupon) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "if customer_can_use_coupon(customer, coupon):\n    apply_coupon(cart, coupon)", "typescript": "if (customerCanUseCoupon(customer, coupon)) {\n  applyCoupon(cart, coupon);\n}"}, "id": "CC-011", "lint_candidates": ["Flag predicate functions that do not start with a question-like prefix."], "lintability": "high", "problem": "Code has a clean-code risk related to we are authors: optimize for readers: Code is read more often than it is written, so make the call site read naturally. Search terms that should match this issue include we are authors: optimize for readers, we are authors optimize for readers, we are, for readers, clean code.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "We Are Authors: Optimize For Readers", "topic": "Clean Code", "use_when": "Use this pattern when planning or reviewing code where code is read more often than it is written, so make the call site read naturally. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["boy scout rule: improve nearby code", "boy scout rule improve nearby code", "boy scout", "nearby code", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-012 Boy Scout Rule: Improve Nearby Code\nTopic: Clean Code\nAliases: boy scout rule: improve nearby code, boy scout rule improve nearby code, boy scout, nearby code, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to boy scout rule: improve nearby code: When editing a module, remove local clutter that directly blocks understanding. Search terms that should match this issue include boy scout rule: improve nearby code, boy scout rule improve nearby code, boy scout, nearby code, clean code.\nUse when: Use this pattern when planning or reviewing code where when editing a module, remove local clutter that directly blocks understanding. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst normalizedPhoneNumber = normalizePhoneNumber(input.phoneNumber);\nawait customerRepository.updatePhoneNumber(customerId, normalizedPhoneNumber);\nGood Python:\nnormalized_phone_number = normalize_phone_number(payload[\"phone_number\"])\ncustomer_repository.update_phone_number(customer_id, normalized_phone_number)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag TODO-free cleanup opportunities in changed hunks, such as newly duplicated expressions.\nLintability: high", "embedding_text": "Clean code pattern CC-012: Boy Scout Rule: Improve Nearby Code. Topic: Clean Code. Rule family: clean_code. Aliases and smell terms: boy scout rule: improve nearby code, boy scout rule improve nearby code, boy scout, nearby code, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to boy scout rule: improve nearby code: When editing a module, remove local clutter that directly blocks understanding. Search terms that should match this issue include boy scout rule: improve nearby code, boy scout rule improve nearby code, boy scout, nearby code, clean code. Use when: Use this pattern when planning or reviewing code where when editing a module, remove local clutter that directly blocks understanding. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Flag TODO-free cleanup opportunities in changed hunks, such as newly duplicated expressions.. Good TypeScript example: const normalizedPhoneNumber = normalizePhoneNumber(input.phoneNumber);\nawait customerRepository.updatePhoneNumber(customerId, normalizedPhoneNumber); Good Python example: normalized_phone_number = normalize_phone_number(payload[\"phone_number\"])\ncustomer_repository.update_phone_number(customer_id, normalized_phone_number) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "normalized_phone_number = normalize_phone_number(payload[\"phone_number\"])\ncustomer_repository.update_phone_number(customer_id, normalized_phone_number)", "typescript": "const normalizedPhoneNumber = normalizePhoneNumber(input.phoneNumber);\nawait customerRepository.updatePhoneNumber(customerId, normalizedPhoneNumber);"}, "id": "CC-012", "lint_candidates": ["Flag TODO-free cleanup opportunities in changed hunks, such as newly duplicated expressions."], "lintability": "high", "problem": "Code has a clean-code risk related to boy scout rule: improve nearby code: When editing a module, remove local clutter that directly blocks understanding. Search terms that should match this issue include boy scout rule: improve nearby code, boy scout rule improve nearby code, boy scout, nearby code, clean code.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Boy Scout Rule: Improve Nearby Code", "topic": "Clean Code", "use_when": "Use this pattern when planning or reviewing code where when editing a module, remove local clutter that directly blocks understanding. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["prequel and principles: use principles as tools", "prequel and principles use principles as tools", "prequel and", "as tools", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-013 Prequel And Principles: Use Principles As Tools\nTopic: Clean Code\nAliases: prequel and principles: use principles as tools, prequel and principles use principles as tools, prequel and, as tools, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to prequel and principles: use principles as tools: Treat clean-code principles as decision aids that make code safer to change. Search terms that should match this issue include prequel and principles: use principles as tools, prequel and principles use principles as tools, prequel and, as tools, clean code.\nUse when: Use this pattern when planning or reviewing code where treat clean-code principles as decision aids that make code safer to change. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nfunction approveLoan(application: LoanApplication): Approval {\n  validateLoanApplication(application);\n  return loanPolicy.approve(application);\n}\nGood Python:\ndef approve_loan(application: LoanApplication) -> Approval:\n    validate_loan_application(application)\n    return loan_policy.approve(application)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: No direct lint rule; use review prompts for validation, transformation, and side-effect separation.\nLintability: review_only", "embedding_text": "Clean code pattern CC-013: Prequel And Principles: Use Principles As Tools. Topic: Clean Code. Rule family: clean_code. Aliases and smell terms: prequel and principles: use principles as tools, prequel and principles use principles as tools, prequel and, as tools, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to prequel and principles: use principles as tools: Treat clean-code principles as decision aids that make code safer to change. Search terms that should match this issue include prequel and principles: use principles as tools, prequel and principles use principles as tools, prequel and, as tools, clean code. Use when: Use this pattern when planning or reviewing code where treat clean-code principles as decision aids that make code safer to change. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: No direct lint rule; use review prompts for validation, transformation, and side-effect separation.. Good TypeScript example: function approveLoan(application: LoanApplication): Approval {\n  validateLoanApplication(application);\n  return loanPolicy.approve(application);\n} Good Python example: def approve_loan(application: LoanApplication) -> Approval:\n    validate_loan_application(application)\n    return loan_policy.approve(application) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def approve_loan(application: LoanApplication) -> Approval:\n    validate_loan_application(application)\n    return loan_policy.approve(application)", "typescript": "function approveLoan(application: LoanApplication): Approval {\n  validateLoanApplication(application);\n  return loanPolicy.approve(application);\n}"}, "id": "CC-013", "lint_candidates": ["No direct lint rule; use review prompts for validation, transformation, and side-effect separation."], "lintability": "review_only", "problem": "Code has a clean-code risk related to prequel and principles: use principles as tools: Treat clean-code principles as decision aids that make code safer to change. Search terms that should match this issue include prequel and principles: use principles as tools, prequel and principles use principles as tools, prequel and, as tools, clean code.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Prequel And Principles: Use Principles As Tools", "topic": "Clean Code", "use_when": "Use this pattern when planning or reviewing code where treat clean-code principles as decision aids that make code safer to change. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["use intention-revealing names", "use intention revealing names", "use intention", "revealing names", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-014 Use Intention-Revealing Names\nTopic: Meaningful Names\nAliases: use intention-revealing names, use intention revealing names, use intention, revealing names, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to use intention-revealing names: Name variables and functions after the domain purpose they serve. Search terms that should match this issue include use intention-revealing names, use intention revealing names, use intention, revealing names, naming smell.\nUse when: Use this pattern when planning or reviewing code where name variables and functions after the domain purpose they serve. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst elapsedDays = daysBetween(invoice.sentAt, now);\n\nif (invoiceIsOverdue(invoice, elapsedDays)) {\n  recordNameExample();\n}\nGood Python:\nelapsed_days = days_between(invoice.sent_at, now)\n\nif invoice_is_overdue(invoice, elapsed_days):\n    record_name_example()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-014: Use Intention-Revealing Names. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: use intention-revealing names, use intention revealing names, use intention, revealing names, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to use intention-revealing names: Name variables and functions after the domain purpose they serve. Search terms that should match this issue include use intention-revealing names, use intention revealing names, use intention, revealing names, naming smell. Use when: Use this pattern when planning or reviewing code where name variables and functions after the domain purpose they serve. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const elapsedDays = daysBetween(invoice.sentAt, now);\n\nif (invoiceIsOverdue(invoice, elapsedDays)) {\n  recordNameExample();\n} Good Python example: elapsed_days = days_between(invoice.sent_at, now)\n\nif invoice_is_overdue(invoice, elapsed_days):\n    record_name_example() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "elapsed_days = days_between(invoice.sent_at, now)\n\nif invoice_is_overdue(invoice, elapsed_days):\n    record_name_example()", "typescript": "const elapsedDays = daysBetween(invoice.sentAt, now);\n\nif (invoiceIsOverdue(invoice, elapsedDays)) {\n  recordNameExample();\n}"}, "id": "CC-014", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to use intention-revealing names: Name variables and functions after the domain purpose they serve. Search terms that should match this issue include use intention-revealing names, use intention revealing names, use intention, revealing names, naming smell.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Use Intention-Revealing Names", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where name variables and functions after the domain purpose they serve. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["avoid disinformation", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-015 Avoid Disinformation\nTopic: Meaningful Names\nAliases: avoid disinformation, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to avoid disinformation: Do not use words that imply the wrong type, unit, or behavior. Search terms that should match this issue include avoid disinformation, naming smell, identifier name, semantic naming, readable name.\nUse when: Use this pattern when planning or reviewing code where do not use words that imply the wrong type, unit, or behavior. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst activeUserIds = new Set(users.filter(isActive).map((user) => user.id));\n\nif (activeUserIds.has(request.userId)) {\n  recordNameExample();\n}\nGood Python:\nactive_user_ids = {user.id for user in users if is_active(user)}\n\nif request.user_id in active_user_ids:\n    record_name_example()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-015: Avoid Disinformation. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: avoid disinformation, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to avoid disinformation: Do not use words that imply the wrong type, unit, or behavior. Search terms that should match this issue include avoid disinformation, naming smell, identifier name, semantic naming, readable name. Use when: Use this pattern when planning or reviewing code where do not use words that imply the wrong type, unit, or behavior. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const activeUserIds = new Set(users.filter(isActive).map((user) => user.id));\n\nif (activeUserIds.has(request.userId)) {\n  recordNameExample();\n} Good Python example: active_user_ids = {user.id for user in users if is_active(user)}\n\nif request.user_id in active_user_ids:\n    record_name_example() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "active_user_ids = {user.id for user in users if is_active(user)}\n\nif request.user_id in active_user_ids:\n    record_name_example()", "typescript": "const activeUserIds = new Set(users.filter(isActive).map((user) => user.id));\n\nif (activeUserIds.has(request.userId)) {\n  recordNameExample();\n}"}, "id": "CC-015", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to avoid disinformation: Do not use words that imply the wrong type, unit, or behavior. Search terms that should match this issue include avoid disinformation, naming smell, identifier name, semantic naming, readable name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Avoid Disinformation", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where do not use words that imply the wrong type, unit, or behavior. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["make meaningful distinctions", "make meaningful", "meaningful distinctions", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-016 Make Meaningful Distinctions\nTopic: Meaningful Names\nAliases: make meaningful distinctions, make meaningful, meaningful distinctions, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to make meaningful distinctions: Distinguish values by their role, not by vague suffixes or numbers. Search terms that should match this issue include make meaningful distinctions, make meaningful, meaningful distinctions, naming smell, identifier name.\nUse when: Use this pattern when planning or reviewing code where distinguish values by their role, not by vague suffixes or numbers. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst approvedAmount = applyAccountLimit(account, requestedAmount);\n\nif (approvedAmount.isLessThan(requestedAmount)) {\n  recordNameExample();\n}\nGood Python:\napproved_amount = apply_account_limit(account, requested_amount)\n\nif approved_amount < requested_amount:\n    record_name_example()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-016: Make Meaningful Distinctions. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: make meaningful distinctions, make meaningful, meaningful distinctions, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to make meaningful distinctions: Distinguish values by their role, not by vague suffixes or numbers. Search terms that should match this issue include make meaningful distinctions, make meaningful, meaningful distinctions, naming smell, identifier name. Use when: Use this pattern when planning or reviewing code where distinguish values by their role, not by vague suffixes or numbers. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const approvedAmount = applyAccountLimit(account, requestedAmount);\n\nif (approvedAmount.isLessThan(requestedAmount)) {\n  recordNameExample();\n} Good Python example: approved_amount = apply_account_limit(account, requested_amount)\n\nif approved_amount < requested_amount:\n    record_name_example() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "approved_amount = apply_account_limit(account, requested_amount)\n\nif approved_amount < requested_amount:\n    record_name_example()", "typescript": "const approvedAmount = applyAccountLimit(account, requestedAmount);\n\nif (approvedAmount.isLessThan(requestedAmount)) {\n  recordNameExample();\n}"}, "id": "CC-016", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to make meaningful distinctions: Distinguish values by their role, not by vague suffixes or numbers. Search terms that should match this issue include make meaningful distinctions, make meaningful, meaningful distinctions, naming smell, identifier name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Make Meaningful Distinctions", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where distinguish values by their role, not by vague suffixes or numbers. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["use pronounceable names", "use pronounceable", "pronounceable names", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-017 Use Pronounceable Names\nTopic: Meaningful Names\nAliases: use pronounceable names, use pronounceable, pronounceable names, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to use pronounceable names: Choose names that people can discuss out loud in reviews. Search terms that should match this issue include use pronounceable names, use pronounceable, pronounceable names, naming smell, identifier name.\nUse when: Use this pattern when planning or reviewing code where choose names that people can discuss out loud in reviews. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst generatedAt = new Date();\n\nif (buildExportRecord(customer, generatedAt)) {\n  recordNameExample();\n}\nGood Python:\ngenerated_at = datetime.now(tz=UTC)\n\nif build_export_record(customer, generated_at):\n    record_name_example()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-017: Use Pronounceable Names. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: use pronounceable names, use pronounceable, pronounceable names, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to use pronounceable names: Choose names that people can discuss out loud in reviews. Search terms that should match this issue include use pronounceable names, use pronounceable, pronounceable names, naming smell, identifier name. Use when: Use this pattern when planning or reviewing code where choose names that people can discuss out loud in reviews. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const generatedAt = new Date();\n\nif (buildExportRecord(customer, generatedAt)) {\n  recordNameExample();\n} Good Python example: generated_at = datetime.now(tz=UTC)\n\nif build_export_record(customer, generated_at):\n    record_name_example() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "generated_at = datetime.now(tz=UTC)\n\nif build_export_record(customer, generated_at):\n    record_name_example()", "typescript": "const generatedAt = new Date();\n\nif (buildExportRecord(customer, generatedAt)) {\n  recordNameExample();\n}"}, "id": "CC-017", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to use pronounceable names: Choose names that people can discuss out loud in reviews. Search terms that should match this issue include use pronounceable names, use pronounceable, pronounceable names, naming smell, identifier name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Use Pronounceable Names", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where choose names that people can discuss out loud in reviews. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["use searchable names", "use searchable", "searchable names", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "if failed_attempts >= 5:\n    lock_account(user_id)", "typescript": "if (failedAttempts >= 5) lockAccount(userId);"}, "display_text": "CC-018 Use Searchable Names\nTopic: Meaningful Names\nAliases: use searchable names, use searchable, searchable names, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to use searchable names: Give important constants and policies names that can be searched. Search terms that should match this issue include use searchable names, use searchable, searchable names, naming smell, identifier name.\nUse when: Use this pattern when planning or reviewing code where give important constants and policies names that can be searched. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst maxLoginAttempts = MAX_LOGIN_ATTEMPTS;\n\nif (failedAttempts >= maxLoginAttempts) {\n  recordNameExample();\n}\nGood Python:\nmax_login_attempts = MAX_LOGIN_ATTEMPTS\n\nif failed_attempts >= max_login_attempts:\n    record_name_example()\nBad TypeScript:\nif (failedAttempts >= 5) lockAccount(userId);\nBad Python:\nif failed_attempts >= 5:\n    lock_account(user_id)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-018: Use Searchable Names. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: use searchable names, use searchable, searchable names, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to use searchable names: Give important constants and policies names that can be searched. Search terms that should match this issue include use searchable names, use searchable, searchable names, naming smell, identifier name. Use when: Use this pattern when planning or reviewing code where give important constants and policies names that can be searched. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const maxLoginAttempts = MAX_LOGIN_ATTEMPTS;\n\nif (failedAttempts >= maxLoginAttempts) {\n  recordNameExample();\n} Good Python example: max_login_attempts = MAX_LOGIN_ATTEMPTS\n\nif failed_attempts >= max_login_attempts:\n    record_name_example() Bad TypeScript example: if (failedAttempts >= 5) lockAccount(userId); Bad Python example: if failed_attempts >= 5:\n    lock_account(user_id)", "good_examples": {"python": "max_login_attempts = MAX_LOGIN_ATTEMPTS\n\nif failed_attempts >= max_login_attempts:\n    record_name_example()", "typescript": "const maxLoginAttempts = MAX_LOGIN_ATTEMPTS;\n\nif (failedAttempts >= maxLoginAttempts) {\n  recordNameExample();\n}"}, "id": "CC-018", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to use searchable names: Give important constants and policies names that can be searched. Search terms that should match this issue include use searchable names, use searchable, searchable names, naming smell, identifier name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Use Searchable Names", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where give important constants and policies names that can be searched. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["avoid encodings", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-019 Avoid Encodings\nTopic: Meaningful Names\nAliases: avoid encodings, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to avoid encodings: Do not encode implementation type into names when types can do that job. Search terms that should match this issue include avoid encodings, naming smell, identifier name, semantic naming, readable name.\nUse when: Use this pattern when planning or reviewing code where do not encode implementation type into names when types can do that job. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst invoiceId = request.invoiceId;\n\nif (loadInvoice(invoiceId)) {\n  recordNameExample();\n}\nGood Python:\ninvoice_id = request.invoice_id\n\nif load_invoice(invoice_id):\n    record_name_example()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-019: Avoid Encodings. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: avoid encodings, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to avoid encodings: Do not encode implementation type into names when types can do that job. Search terms that should match this issue include avoid encodings, naming smell, identifier name, semantic naming, readable name. Use when: Use this pattern when planning or reviewing code where do not encode implementation type into names when types can do that job. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const invoiceId = request.invoiceId;\n\nif (loadInvoice(invoiceId)) {\n  recordNameExample();\n} Good Python example: invoice_id = request.invoice_id\n\nif load_invoice(invoice_id):\n    record_name_example() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "invoice_id = request.invoice_id\n\nif load_invoice(invoice_id):\n    record_name_example()", "typescript": "const invoiceId = request.invoiceId;\n\nif (loadInvoice(invoiceId)) {\n  recordNameExample();\n}"}, "id": "CC-019", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to avoid encodings: Do not encode implementation type into names when types can do that job. Search terms that should match this issue include avoid encodings, naming smell, identifier name, semantic naming, readable name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Avoid Encodings", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where do not encode implementation type into names when types can do that job. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["hungarian notation", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-020 Hungarian Notation\nTopic: Meaningful Names\nAliases: hungarian notation, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to hungarian notation: Avoid prefixes like str, int, or arr that duplicate type information. Search terms that should match this issue include hungarian notation, naming smell, identifier name, semantic naming, readable name.\nUse when: Use this pattern when planning or reviewing code where avoid prefixes like str, int, or arr that duplicate type information. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst customerEmail = customer.email;\n\nif (sendReceipt(customerEmail)) {\n  recordNameExample();\n}\nGood Python:\ncustomer_email = customer.email\n\nif send_receipt(customer_email):\n    record_name_example()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-020: Hungarian Notation. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: hungarian notation, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to hungarian notation: Avoid prefixes like str, int, or arr that duplicate type information. Search terms that should match this issue include hungarian notation, naming smell, identifier name, semantic naming, readable name. Use when: Use this pattern when planning or reviewing code where avoid prefixes like str, int, or arr that duplicate type information. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const customerEmail = customer.email;\n\nif (sendReceipt(customerEmail)) {\n  recordNameExample();\n} Good Python example: customer_email = customer.email\n\nif send_receipt(customer_email):\n    record_name_example() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "customer_email = customer.email\n\nif send_receipt(customer_email):\n    record_name_example()", "typescript": "const customerEmail = customer.email;\n\nif (sendReceipt(customerEmail)) {\n  recordNameExample();\n}"}, "id": "CC-020", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to hungarian notation: Avoid prefixes like str, int, or arr that duplicate type information. Search terms that should match this issue include hungarian notation, naming smell, identifier name, semantic naming, readable name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Hungarian Notation", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where avoid prefixes like str, int, or arr that duplicate type information. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["member prefixes", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-021 Member Prefixes\nTopic: Meaningful Names\nAliases: member prefixes, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to member prefixes: Avoid noisy member prefixes when class structure already provides context. Search terms that should match this issue include member prefixes, naming smell, identifier name, semantic naming, readable name.\nUse when: Use this pattern when planning or reviewing code where avoid noisy member prefixes when class structure already provides context. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst balance = initialBalance;\n\nif (new Wallet(balance)) {\n  recordNameExample();\n}\nGood Python:\nbalance = initial_balance\n\nif Wallet(balance):\n    record_name_example()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-021: Member Prefixes. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: member prefixes, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to member prefixes: Avoid noisy member prefixes when class structure already provides context. Search terms that should match this issue include member prefixes, naming smell, identifier name, semantic naming, readable name. Use when: Use this pattern when planning or reviewing code where avoid noisy member prefixes when class structure already provides context. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const balance = initialBalance;\n\nif (new Wallet(balance)) {\n  recordNameExample();\n} Good Python example: balance = initial_balance\n\nif Wallet(balance):\n    record_name_example() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "balance = initial_balance\n\nif Wallet(balance):\n    record_name_example()", "typescript": "const balance = initialBalance;\n\nif (new Wallet(balance)) {\n  recordNameExample();\n}"}, "id": "CC-021", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to member prefixes: Avoid noisy member prefixes when class structure already provides context. Search terms that should match this issue include member prefixes, naming smell, identifier name, semantic naming, readable name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Member Prefixes", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where avoid noisy member prefixes when class structure already provides context. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["interfaces and implementations", "interfaces and", "and implementations", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-022 Interfaces And Implementations\nTopic: Meaningful Names\nAliases: interfaces and implementations, interfaces and, and implementations, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to interfaces and implementations: Name abstractions for the role callers need, not for mechanical implementation details. Search terms that should match this issue include interfaces and implementations, interfaces and, and implementations, naming smell, identifier name.\nUse when: Use this pattern when planning or reviewing code where name abstractions for the role callers need, not for mechanical implementation details. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst paymentGateway = new StripePaymentGateway(client);\n\nif (paymentGateway.capture(request)) {\n  recordNameExample();\n}\nGood Python:\npayment_gateway = StripePaymentGateway(client)\n\nif payment_gateway.capture(request):\n    record_name_example()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-022: Interfaces And Implementations. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: interfaces and implementations, interfaces and, and implementations, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to interfaces and implementations: Name abstractions for the role callers need, not for mechanical implementation details. Search terms that should match this issue include interfaces and implementations, interfaces and, and implementations, naming smell, identifier name. Use when: Use this pattern when planning or reviewing code where name abstractions for the role callers need, not for mechanical implementation details. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const paymentGateway = new StripePaymentGateway(client);\n\nif (paymentGateway.capture(request)) {\n  recordNameExample();\n} Good Python example: payment_gateway = StripePaymentGateway(client)\n\nif payment_gateway.capture(request):\n    record_name_example() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "payment_gateway = StripePaymentGateway(client)\n\nif payment_gateway.capture(request):\n    record_name_example()", "typescript": "const paymentGateway = new StripePaymentGateway(client);\n\nif (paymentGateway.capture(request)) {\n  recordNameExample();\n}"}, "id": "CC-022", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to interfaces and implementations: Name abstractions for the role callers need, not for mechanical implementation details. Search terms that should match this issue include interfaces and implementations, interfaces and, and implementations, naming smell, identifier name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Interfaces And Implementations", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where name abstractions for the role callers need, not for mechanical implementation details. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["avoid mental mapping", "avoid mental", "mental mapping", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-023 Avoid Mental Mapping\nTopic: Meaningful Names\nAliases: avoid mental mapping, avoid mental, mental mapping, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to avoid mental mapping: Do not require readers to translate terse aliases into domain terms. Search terms that should match this issue include avoid mental mapping, avoid mental, mental mapping, naming smell, identifier name.\nUse when: Use this pattern when planning or reviewing code where do not require readers to translate terse aliases into domain terms. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst paymentMethod = customer.paymentMethods[0];\n\nif (verifyPaymentMethod(paymentMethod)) {\n  recordNameExample();\n}\nGood Python:\npayment_method = customer.payment_methods[0]\n\nif verify_payment_method(payment_method):\n    record_name_example()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-023: Avoid Mental Mapping. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: avoid mental mapping, avoid mental, mental mapping, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to avoid mental mapping: Do not require readers to translate terse aliases into domain terms. Search terms that should match this issue include avoid mental mapping, avoid mental, mental mapping, naming smell, identifier name. Use when: Use this pattern when planning or reviewing code where do not require readers to translate terse aliases into domain terms. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const paymentMethod = customer.paymentMethods[0];\n\nif (verifyPaymentMethod(paymentMethod)) {\n  recordNameExample();\n} Good Python example: payment_method = customer.payment_methods[0]\n\nif verify_payment_method(payment_method):\n    record_name_example() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "payment_method = customer.payment_methods[0]\n\nif verify_payment_method(payment_method):\n    record_name_example()", "typescript": "const paymentMethod = customer.paymentMethods[0];\n\nif (verifyPaymentMethod(paymentMethod)) {\n  recordNameExample();\n}"}, "id": "CC-023", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to avoid mental mapping: Do not require readers to translate terse aliases into domain terms. Search terms that should match this issue include avoid mental mapping, avoid mental, mental mapping, naming smell, identifier name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Avoid Mental Mapping", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where do not require readers to translate terse aliases into domain terms. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["class names", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-024 Class Names\nTopic: Meaningful Names\nAliases: class names, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to class names: Use noun or noun-phrase class names for domain concepts. Search terms that should match this issue include class names, naming smell, identifier name, semantic naming, readable name.\nUse when: Use this pattern when planning or reviewing code where use noun or noun-phrase class names for domain concepts. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst retryPolicy = new RetryPolicy(3);\n\nif (retryPolicy.shouldRetry(attempt)) {\n  recordNameExample();\n}\nGood Python:\nretry_policy = RetryPolicy(max_attempts=3)\n\nif retry_policy.should_retry(attempt):\n    record_name_example()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-024: Class Names. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: class names, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to class names: Use noun or noun-phrase class names for domain concepts. Search terms that should match this issue include class names, naming smell, identifier name, semantic naming, readable name. Use when: Use this pattern when planning or reviewing code where use noun or noun-phrase class names for domain concepts. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const retryPolicy = new RetryPolicy(3);\n\nif (retryPolicy.shouldRetry(attempt)) {\n  recordNameExample();\n} Good Python example: retry_policy = RetryPolicy(max_attempts=3)\n\nif retry_policy.should_retry(attempt):\n    record_name_example() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "retry_policy = RetryPolicy(max_attempts=3)\n\nif retry_policy.should_retry(attempt):\n    record_name_example()", "typescript": "const retryPolicy = new RetryPolicy(3);\n\nif (retryPolicy.shouldRetry(attempt)) {\n  recordNameExample();\n}"}, "id": "CC-024", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to class names: Use noun or noun-phrase class names for domain concepts. Search terms that should match this issue include class names, naming smell, identifier name, semantic naming, readable name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Class Names", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where use noun or noun-phrase class names for domain concepts. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["method names", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-025 Method Names\nTopic: Meaningful Names\nAliases: method names, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to method names: Use verb or verb-phrase method names that describe the action or question. Search terms that should match this issue include method names, naming smell, identifier name, semantic naming, readable name.\nUse when: Use this pattern when planning or reviewing code where use verb or verb-phrase method names that describe the action or question. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst isEligible = loyaltyPolicy.isEligible(customer);\n\nif (isEligible) {\n  recordNameExample();\n}\nGood Python:\nis_eligible = loyalty_policy.is_eligible(customer)\n\nif is_eligible:\n    record_name_example()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-025: Method Names. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: method names, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to method names: Use verb or verb-phrase method names that describe the action or question. Search terms that should match this issue include method names, naming smell, identifier name, semantic naming, readable name. Use when: Use this pattern when planning or reviewing code where use verb or verb-phrase method names that describe the action or question. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const isEligible = loyaltyPolicy.isEligible(customer);\n\nif (isEligible) {\n  recordNameExample();\n} Good Python example: is_eligible = loyalty_policy.is_eligible(customer)\n\nif is_eligible:\n    record_name_example() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "is_eligible = loyalty_policy.is_eligible(customer)\n\nif is_eligible:\n    record_name_example()", "typescript": "const isEligible = loyaltyPolicy.isEligible(customer);\n\nif (isEligible) {\n  recordNameExample();\n}"}, "id": "CC-025", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to method names: Use verb or verb-phrase method names that describe the action or question. Search terms that should match this issue include method names, naming smell, identifier name, semantic naming, readable name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Method Names", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where use verb or verb-phrase method names that describe the action or question. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["do not be cute", "do not", "be cute", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-026 Do Not Be Cute\nTopic: Meaningful Names\nAliases: do not be cute, do not, be cute, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to do not be cute: Prefer clear domain language over jokes, slang, or surprising metaphors. Search terms that should match this issue include do not be cute, do not, be cute, naming smell, identifier name.\nUse when: Use this pattern when planning or reviewing code where prefer clear domain language over jokes, slang, or surprising metaphors. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst deleteExpiredSessions = sessionRepository;\n\nif (deleteExpiredSessions(sessionRepository)) {\n  recordNameExample();\n}\nGood Python:\ndelete_expired_sessions = session_repository\n\nif delete_expired_sessions(session_repository):\n    record_name_example()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-026: Do Not Be Cute. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: do not be cute, do not, be cute, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to do not be cute: Prefer clear domain language over jokes, slang, or surprising metaphors. Search terms that should match this issue include do not be cute, do not, be cute, naming smell, identifier name. Use when: Use this pattern when planning or reviewing code where prefer clear domain language over jokes, slang, or surprising metaphors. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const deleteExpiredSessions = sessionRepository;\n\nif (deleteExpiredSessions(sessionRepository)) {\n  recordNameExample();\n} Good Python example: delete_expired_sessions = session_repository\n\nif delete_expired_sessions(session_repository):\n    record_name_example() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "delete_expired_sessions = session_repository\n\nif delete_expired_sessions(session_repository):\n    record_name_example()", "typescript": "const deleteExpiredSessions = sessionRepository;\n\nif (deleteExpiredSessions(sessionRepository)) {\n  recordNameExample();\n}"}, "id": "CC-026", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to do not be cute: Prefer clear domain language over jokes, slang, or surprising metaphors. Search terms that should match this issue include do not be cute, do not, be cute, naming smell, identifier name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Do Not Be Cute", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where prefer clear domain language over jokes, slang, or surprising metaphors. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["pick one word per concept", "pick one", "per concept", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-027 Pick One Word Per Concept\nTopic: Meaningful Names\nAliases: pick one word per concept, pick one, per concept, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to pick one word per concept: Use one verb for one operation across a codebase. Search terms that should match this issue include pick one word per concept, pick one, per concept, naming smell, identifier name.\nUse when: Use this pattern when planning or reviewing code where use one verb for one operation across a codebase. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst fetchOrder = orderRepository;\n\nif (fetchOrder(orderId)) {\n  recordNameExample();\n}\nGood Python:\nfetch_order = order_repository\n\nif fetch_order(order_id):\n    record_name_example()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-027: Pick One Word Per Concept. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: pick one word per concept, pick one, per concept, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to pick one word per concept: Use one verb for one operation across a codebase. Search terms that should match this issue include pick one word per concept, pick one, per concept, naming smell, identifier name. Use when: Use this pattern when planning or reviewing code where use one verb for one operation across a codebase. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const fetchOrder = orderRepository;\n\nif (fetchOrder(orderId)) {\n  recordNameExample();\n} Good Python example: fetch_order = order_repository\n\nif fetch_order(order_id):\n    record_name_example() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "fetch_order = order_repository\n\nif fetch_order(order_id):\n    record_name_example()", "typescript": "const fetchOrder = orderRepository;\n\nif (fetchOrder(orderId)) {\n  recordNameExample();\n}"}, "id": "CC-027", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to pick one word per concept: Use one verb for one operation across a codebase. Search terms that should match this issue include pick one word per concept, pick one, per concept, naming smell, identifier name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Pick One Word Per Concept", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where use one verb for one operation across a codebase. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["do not pun", "do not", "not pun", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-028 Do Not Pun\nTopic: Meaningful Names\nAliases: do not pun, do not, not pun, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to do not pun: Do not reuse the same word for unrelated operations. Search terms that should match this issue include do not pun, do not, not pun, naming smell, identifier name.\nUse when: Use this pattern when planning or reviewing code where do not reuse the same word for unrelated operations. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst appendAuditEvent = auditLog;\n\nif (appendAuditEvent(auditLog, event)) {\n  recordNameExample();\n}\nGood Python:\nappend_audit_event = audit_log\n\nif append_audit_event(audit_log, event):\n    record_name_example()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-028: Do Not Pun. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: do not pun, do not, not pun, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to do not pun: Do not reuse the same word for unrelated operations. Search terms that should match this issue include do not pun, do not, not pun, naming smell, identifier name. Use when: Use this pattern when planning or reviewing code where do not reuse the same word for unrelated operations. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const appendAuditEvent = auditLog;\n\nif (appendAuditEvent(auditLog, event)) {\n  recordNameExample();\n} Good Python example: append_audit_event = audit_log\n\nif append_audit_event(audit_log, event):\n    record_name_example() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "append_audit_event = audit_log\n\nif append_audit_event(audit_log, event):\n    record_name_example()", "typescript": "const appendAuditEvent = auditLog;\n\nif (appendAuditEvent(auditLog, event)) {\n  recordNameExample();\n}"}, "id": "CC-028", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to do not pun: Do not reuse the same word for unrelated operations. Search terms that should match this issue include do not pun, do not, not pun, naming smell, identifier name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Do Not Pun", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where do not reuse the same word for unrelated operations. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["use solution domain names", "use solution", "domain names", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-029 Use Solution Domain Names\nTopic: Meaningful Names\nAliases: use solution domain names, use solution, domain names, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to use solution domain names: Use established programming terms when the concept is technical. Search terms that should match this issue include use solution domain names, use solution, domain names, naming smell, identifier name.\nUse when: Use this pattern when planning or reviewing code where use established programming terms when the concept is technical. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst paymentQueue = new AsyncQueue<PaymentJob>();\n\nif (paymentQueue.enqueue(job)) {\n  recordNameExample();\n}\nGood Python:\npayment_queue = AsyncQueue[PaymentJob]()\n\nif payment_queue.enqueue(job):\n    record_name_example()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-029: Use Solution Domain Names. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: use solution domain names, use solution, domain names, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to use solution domain names: Use established programming terms when the concept is technical. Search terms that should match this issue include use solution domain names, use solution, domain names, naming smell, identifier name. Use when: Use this pattern when planning or reviewing code where use established programming terms when the concept is technical. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const paymentQueue = new AsyncQueue<PaymentJob>();\n\nif (paymentQueue.enqueue(job)) {\n  recordNameExample();\n} Good Python example: payment_queue = AsyncQueue[PaymentJob]()\n\nif payment_queue.enqueue(job):\n    record_name_example() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "payment_queue = AsyncQueue[PaymentJob]()\n\nif payment_queue.enqueue(job):\n    record_name_example()", "typescript": "const paymentQueue = new AsyncQueue<PaymentJob>();\n\nif (paymentQueue.enqueue(job)) {\n  recordNameExample();\n}"}, "id": "CC-029", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to use solution domain names: Use established programming terms when the concept is technical. Search terms that should match this issue include use solution domain names, use solution, domain names, naming smell, identifier name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Use Solution Domain Names", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where use established programming terms when the concept is technical. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["use problem domain names", "use problem", "domain names", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-030 Use Problem Domain Names\nTopic: Meaningful Names\nAliases: use problem domain names, use problem, domain names, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to use problem domain names: Use business vocabulary when naming business concepts. Search terms that should match this issue include use problem domain names, use problem, domain names, naming smell, identifier name.\nUse when: Use this pattern when planning or reviewing code where use business vocabulary when naming business concepts. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst settlementWindow = bankingCalendar.nextWindow(now);\n\nif (settlementWindow.includes(now)) {\n  recordNameExample();\n}\nGood Python:\nsettlement_window = banking_calendar.next_window(now)\n\nif settlement_window.includes(now):\n    record_name_example()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-030: Use Problem Domain Names. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: use problem domain names, use problem, domain names, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to use problem domain names: Use business vocabulary when naming business concepts. Search terms that should match this issue include use problem domain names, use problem, domain names, naming smell, identifier name. Use when: Use this pattern when planning or reviewing code where use business vocabulary when naming business concepts. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const settlementWindow = bankingCalendar.nextWindow(now);\n\nif (settlementWindow.includes(now)) {\n  recordNameExample();\n} Good Python example: settlement_window = banking_calendar.next_window(now)\n\nif settlement_window.includes(now):\n    record_name_example() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "settlement_window = banking_calendar.next_window(now)\n\nif settlement_window.includes(now):\n    record_name_example()", "typescript": "const settlementWindow = bankingCalendar.nextWindow(now);\n\nif (settlementWindow.includes(now)) {\n  recordNameExample();\n}"}, "id": "CC-030", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to use problem domain names: Use business vocabulary when naming business concepts. Search terms that should match this issue include use problem domain names, use problem, domain names, naming smell, identifier name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Use Problem Domain Names", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where use business vocabulary when naming business concepts. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["add meaningful context", "add meaningful", "meaningful context", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-031 Add Meaningful Context\nTopic: Meaningful Names\nAliases: add meaningful context, add meaningful, meaningful context, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to add meaningful context: Add context where a value is otherwise ambiguous. Search terms that should match this issue include add meaningful context, add meaningful, meaningful context, naming smell, identifier name.\nUse when: Use this pattern when planning or reviewing code where add context where a value is otherwise ambiguous. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst shippingAddress = parseAddress(order.shipping);\n\nif (validateShippingAddress(shippingAddress)) {\n  recordNameExample();\n}\nGood Python:\nshipping_address = parse_address(order.shipping)\n\nif validate_shipping_address(shipping_address):\n    record_name_example()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-031: Add Meaningful Context. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: add meaningful context, add meaningful, meaningful context, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to add meaningful context: Add context where a value is otherwise ambiguous. Search terms that should match this issue include add meaningful context, add meaningful, meaningful context, naming smell, identifier name. Use when: Use this pattern when planning or reviewing code where add context where a value is otherwise ambiguous. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const shippingAddress = parseAddress(order.shipping);\n\nif (validateShippingAddress(shippingAddress)) {\n  recordNameExample();\n} Good Python example: shipping_address = parse_address(order.shipping)\n\nif validate_shipping_address(shipping_address):\n    record_name_example() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "shipping_address = parse_address(order.shipping)\n\nif validate_shipping_address(shipping_address):\n    record_name_example()", "typescript": "const shippingAddress = parseAddress(order.shipping);\n\nif (validateShippingAddress(shippingAddress)) {\n  recordNameExample();\n}"}, "id": "CC-031", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to add meaningful context: Add context where a value is otherwise ambiguous. Search terms that should match this issue include add meaningful context, add meaningful, meaningful context, naming smell, identifier name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Add Meaningful Context", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where add context where a value is otherwise ambiguous. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["do not add gratuitous context", "do not", "gratuitous context", "naming smell", "identifier name", "semantic naming", "readable name", "meaningful names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-032 Do Not Add Gratuitous Context\nTopic: Meaningful Names\nAliases: do not add gratuitous context, do not, gratuitous context, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to do not add gratuitous context: Avoid repeating module or class context in every member name. Search terms that should match this issue include do not add gratuitous context, do not, gratuitous context, naming smell, identifier name.\nUse when: Use this pattern when planning or reviewing code where avoid repeating module or class context in every member name. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst postalCode = address.postalCode;\n\nif (validatePostalCode(postalCode)) {\n  recordNameExample();\n}\nGood Python:\npostal_code = address.postal_code\n\nif validate_postal_code(postal_code):\n    record_name_example()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.\nLintability: high", "embedding_text": "Clean code pattern CC-032: Do Not Add Gratuitous Context. Topic: Meaningful Names. Rule family: naming. Aliases and smell terms: do not add gratuitous context, do not, gratuitous context, naming smell, identifier name, semantic naming, readable name, meaningful names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to do not add gratuitous context: Avoid repeating module or class context in every member name. Search terms that should match this issue include do not add gratuitous context, do not, gratuitous context, naming smell, identifier name. Use when: Use this pattern when planning or reviewing code where avoid repeating module or class context in every member name. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists.. Good TypeScript example: const postalCode = address.postalCode;\n\nif (validatePostalCode(postalCode)) {\n  recordNameExample();\n} Good Python example: postal_code = address.postal_code\n\nif validate_postal_code(postal_code):\n    record_name_example() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "postal_code = address.postal_code\n\nif validate_postal_code(postal_code):\n    record_name_example()", "typescript": "const postalCode = address.postalCode;\n\nif (validatePostalCode(postalCode)) {\n  recordNameExample();\n}"}, "id": "CC-032", "lint_candidates": ["Flag vague, misleading, inconsistent, or type-encoded names according to local allowlists."], "lintability": "high", "problem": "Code has a clean-code risk related to do not add gratuitous context: Avoid repeating module or class context in every member name. Search terms that should match this issue include do not add gratuitous context, do not, gratuitous context, naming smell, identifier name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Do Not Add Gratuitous Context", "topic": "Meaningful Names", "use_when": "Use this pattern when planning or reviewing code where avoid repeating module or class context in every member name. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["small functions", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-033 Small Functions\nTopic: Functions\nAliases: small functions, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to small functions: Keep functions short enough that the main idea is immediately visible. Search terms that should match this issue include small functions, function smell, single responsibility, small function, function design.\nUse when: Use this pattern when planning or reviewing code where keep functions short enough that the main idea is immediately visible. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nfunction canPlaceOrder(account: Account, quote: Quote): boolean {\n  return hasVerifiedIdentity(account) && hasEnoughBalance(account, quote.total);\n}\nGood Python:\ndef can_place_order(account: Account, quote: Quote) -> bool:\n    return has_verified_identity(account) and has_enough_balance(account, quote.total)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-033: Small Functions. Topic: Functions. Rule family: functions. Aliases and smell terms: small functions, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to small functions: Keep functions short enough that the main idea is immediately visible. Search terms that should match this issue include small functions, function smell, single responsibility, small function, function design. Use when: Use this pattern when planning or reviewing code where keep functions short enough that the main idea is immediately visible. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: function canPlaceOrder(account: Account, quote: Quote): boolean {\n  return hasVerifiedIdentity(account) && hasEnoughBalance(account, quote.total);\n} Good Python example: def can_place_order(account: Account, quote: Quote) -> bool:\n    return has_verified_identity(account) and has_enough_balance(account, quote.total) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def can_place_order(account: Account, quote: Quote) -> bool:\n    return has_verified_identity(account) and has_enough_balance(account, quote.total)", "typescript": "function canPlaceOrder(account: Account, quote: Quote): boolean {\n  return hasVerifiedIdentity(account) && hasEnoughBalance(account, quote.total);\n}"}, "id": "CC-033", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to small functions: Keep functions short enough that the main idea is immediately visible. Search terms that should match this issue include small functions, function smell, single responsibility, small function, function design.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Small Functions", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where keep functions short enough that the main idea is immediately visible. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["blocks and indenting", "blocks and", "and indenting", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-034 Blocks And Indenting\nTopic: Functions\nAliases: blocks and indenting, blocks and, and indenting, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to blocks and indenting: Keep blocks shallow so readers can follow the happy path without scanning a maze. Search terms that should match this issue include blocks and indenting, blocks and, and indenting, function smell, single responsibility.\nUse when: Use this pattern when planning or reviewing code where keep blocks shallow so readers can follow the happy path without scanning a maze. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nfunction priceOrder(order: Order): Money {\n  if (order.items.length === 0) throw new EmptyOrderError();\n  return order.items.reduce(addItemPrice, money('0.00'));\n}\nGood Python:\ndef price_order(order: Order) -> Money:\n    if not order.items:\n        raise EmptyOrderError()\n    return sum_item_prices(order.items)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-034: Blocks And Indenting. Topic: Functions. Rule family: functions. Aliases and smell terms: blocks and indenting, blocks and, and indenting, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to blocks and indenting: Keep blocks shallow so readers can follow the happy path without scanning a maze. Search terms that should match this issue include blocks and indenting, blocks and, and indenting, function smell, single responsibility. Use when: Use this pattern when planning or reviewing code where keep blocks shallow so readers can follow the happy path without scanning a maze. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: function priceOrder(order: Order): Money {\n  if (order.items.length === 0) throw new EmptyOrderError();\n  return order.items.reduce(addItemPrice, money('0.00'));\n} Good Python example: def price_order(order: Order) -> Money:\n    if not order.items:\n        raise EmptyOrderError()\n    return sum_item_prices(order.items) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def price_order(order: Order) -> Money:\n    if not order.items:\n        raise EmptyOrderError()\n    return sum_item_prices(order.items)", "typescript": "function priceOrder(order: Order): Money {\n  if (order.items.length === 0) throw new EmptyOrderError();\n  return order.items.reduce(addItemPrice, money('0.00'));\n}"}, "id": "CC-034", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to blocks and indenting: Keep blocks shallow so readers can follow the happy path without scanning a maze. Search terms that should match this issue include blocks and indenting, blocks and, and indenting, function smell, single responsibility.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Blocks And Indenting", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where keep blocks shallow so readers can follow the happy path without scanning a maze. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["do one thing", "do one", "one thing", "function smell", "single responsibility", "small function", "function design", "mixed responsibility", "function cohesion", "functions", "clean code", "code smell"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "def submit_order(payload):\n    validate(payload)\n    db.save(payload)\n    email(payload)", "typescript": "async function submitOrder(input) { validate(input); await db.save(input); await email(input); }"}, "display_text": "CC-035 Do One Thing\nTopic: Functions\nAliases: do one thing, do one, one thing, function smell, single responsibility, small function, function design, mixed responsibility, function cohesion, functions, clean code, code smell\nProblem: Code has a clean-code risk related to do one thing: A function should combine steps at one purpose, not unrelated responsibilities. Search terms that should match this issue include do one thing, do one, one thing, function smell, single responsibility.\nUse when: Use this pattern when planning or reviewing code where a function should combine steps at one purpose, not unrelated responsibilities. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nasync function submitOrder(input: OrderInput): Promise<OrderReceipt> {\n  const order = buildOrder(validateOrderInput(input));\n  return orderGateway.submit(order);\n}\nGood Python:\ndef submit_order(payload: OrderPayload) -> OrderReceipt:\n    order = build_order(validate_order_payload(payload))\n    return order_gateway.submit(order)\nBad TypeScript:\nasync function submitOrder(input) { validate(input); await db.save(input); await email(input); }\nBad Python:\ndef submit_order(payload):\n    validate(payload)\n    db.save(payload)\n    email(payload)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-035: Do One Thing. Topic: Functions. Rule family: functions. Aliases and smell terms: do one thing, do one, one thing, function smell, single responsibility, small function, function design, mixed responsibility, function cohesion, functions, clean code, code smell. Problem: Code has a clean-code risk related to do one thing: A function should combine steps at one purpose, not unrelated responsibilities. Search terms that should match this issue include do one thing, do one, one thing, function smell, single responsibility. Use when: Use this pattern when planning or reviewing code where a function should combine steps at one purpose, not unrelated responsibilities. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: async function submitOrder(input: OrderInput): Promise<OrderReceipt> {\n  const order = buildOrder(validateOrderInput(input));\n  return orderGateway.submit(order);\n} Good Python example: def submit_order(payload: OrderPayload) -> OrderReceipt:\n    order = build_order(validate_order_payload(payload))\n    return order_gateway.submit(order) Bad TypeScript example: async function submitOrder(input) { validate(input); await db.save(input); await email(input); } Bad Python example: def submit_order(payload):\n    validate(payload)\n    db.save(payload)\n    email(payload)", "good_examples": {"python": "def submit_order(payload: OrderPayload) -> OrderReceipt:\n    order = build_order(validate_order_payload(payload))\n    return order_gateway.submit(order)", "typescript": "async function submitOrder(input: OrderInput): Promise<OrderReceipt> {\n  const order = buildOrder(validateOrderInput(input));\n  return orderGateway.submit(order);\n}"}, "id": "CC-035", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to do one thing: A function should combine steps at one purpose, not unrelated responsibilities. Search terms that should match this issue include do one thing, do one, one thing, function smell, single responsibility.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Do One Thing", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where a function should combine steps at one purpose, not unrelated responsibilities. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["sections within functions", "sections within", "within functions", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-036 Sections Within Functions\nTopic: Functions\nAliases: sections within functions, sections within, within functions, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to sections within functions: If a function has visible sections, extract them into named helpers. Search terms that should match this issue include sections within functions, sections within, within functions, function smell, single responsibility.\nUse when: Use this pattern when planning or reviewing code where if a function has visible sections, extract them into named helpers. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nfunction registerCustomer(input: SignupInput): Promise<Customer> {\n  const customer = createCustomer(input);\n  return welcomeCustomer(customer);\n}\nGood Python:\ndef register_customer(payload: SignupPayload) -> Customer:\n    customer = create_customer(payload)\n    return welcome_customer(customer)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-036: Sections Within Functions. Topic: Functions. Rule family: functions. Aliases and smell terms: sections within functions, sections within, within functions, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to sections within functions: If a function has visible sections, extract them into named helpers. Search terms that should match this issue include sections within functions, sections within, within functions, function smell, single responsibility. Use when: Use this pattern when planning or reviewing code where if a function has visible sections, extract them into named helpers. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: function registerCustomer(input: SignupInput): Promise<Customer> {\n  const customer = createCustomer(input);\n  return welcomeCustomer(customer);\n} Good Python example: def register_customer(payload: SignupPayload) -> Customer:\n    customer = create_customer(payload)\n    return welcome_customer(customer) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def register_customer(payload: SignupPayload) -> Customer:\n    customer = create_customer(payload)\n    return welcome_customer(customer)", "typescript": "function registerCustomer(input: SignupInput): Promise<Customer> {\n  const customer = createCustomer(input);\n  return welcomeCustomer(customer);\n}"}, "id": "CC-036", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to sections within functions: If a function has visible sections, extract them into named helpers. Search terms that should match this issue include sections within functions, sections within, within functions, function smell, single responsibility.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Sections Within Functions", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where if a function has visible sections, extract them into named helpers. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["one level of abstraction per function", "one level", "per function", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-037 One Level Of Abstraction Per Function\nTopic: Functions\nAliases: one level of abstraction per function, one level, per function, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to one level of abstraction per function: Do not mix domain steps with low-level parsing or protocol details in the same function. Search terms that should match this issue include one level of abstraction per function, one level, per function, function smell, single responsibility.\nUse when: Use this pattern when planning or reviewing code where do not mix domain steps with low-level parsing or protocol details in the same function. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nasync function onboardCustomer(form: SignupForm): Promise<Customer> {\n  const customer = createCustomerProfile(form);\n  await sendWelcomeEmail(customer);\n  return customer;\n}\nGood Python:\nasync def onboard_customer(form: SignupForm) -> Customer:\n    customer = create_customer_profile(form)\n    await send_welcome_email(customer)\n    return customer\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-037: One Level Of Abstraction Per Function. Topic: Functions. Rule family: functions. Aliases and smell terms: one level of abstraction per function, one level, per function, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to one level of abstraction per function: Do not mix domain steps with low-level parsing or protocol details in the same function. Search terms that should match this issue include one level of abstraction per function, one level, per function, function smell, single responsibility. Use when: Use this pattern when planning or reviewing code where do not mix domain steps with low-level parsing or protocol details in the same function. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: async function onboardCustomer(form: SignupForm): Promise<Customer> {\n  const customer = createCustomerProfile(form);\n  await sendWelcomeEmail(customer);\n  return customer;\n} Good Python example: async def onboard_customer(form: SignupForm) -> Customer:\n    customer = create_customer_profile(form)\n    await send_welcome_email(customer)\n    return customer Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "async def onboard_customer(form: SignupForm) -> Customer:\n    customer = create_customer_profile(form)\n    await send_welcome_email(customer)\n    return customer", "typescript": "async function onboardCustomer(form: SignupForm): Promise<Customer> {\n  const customer = createCustomerProfile(form);\n  await sendWelcomeEmail(customer);\n  return customer;\n}"}, "id": "CC-037", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to one level of abstraction per function: Do not mix domain steps with low-level parsing or protocol details in the same function. Search terms that should match this issue include one level of abstraction per function, one level, per function, function smell, single responsibility.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "One Level Of Abstraction Per Function", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where do not mix domain steps with low-level parsing or protocol details in the same function. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["stepdown rule", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-038 Stepdown Rule\nTopic: Functions\nAliases: stepdown rule, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to stepdown rule: Order functions so high-level behavior leads readers down into details. Search terms that should match this issue include stepdown rule, function smell, single responsibility, small function, function design.\nUse when: Use this pattern when planning or reviewing code where order functions so high-level behavior leads readers down into details. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nasync function closeAccount(id: string): Promise<void> {\n  const account = await loadClosableAccount(id);\n  await archiveAccount(account);\n}\n\nfunction loadClosableAccount(id: string): Promise<Account> {\n  return accountRepository.getClosable(id);\n}\nGood Python:\ndef close_account(account_id: str) -> None:\n    account = load_closable_account(account_id)\n    archive_account(account)\n\ndef load_closable_account(account_id: str) -> Account:\n    return account_repository.get_closable(account_id)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-038: Stepdown Rule. Topic: Functions. Rule family: functions. Aliases and smell terms: stepdown rule, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to stepdown rule: Order functions so high-level behavior leads readers down into details. Search terms that should match this issue include stepdown rule, function smell, single responsibility, small function, function design. Use when: Use this pattern when planning or reviewing code where order functions so high-level behavior leads readers down into details. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: async function closeAccount(id: string): Promise<void> {\n  const account = await loadClosableAccount(id);\n  await archiveAccount(account);\n}\n\nfunction loadClosableAccount(id: string): Promise<Account> {\n  return accountRepository.getClosable(id);\n} Good Python example: def close_account(account_id: str) -> None:\n    account = load_closable_account(account_id)\n    archive_account(account)\n\ndef load_closable_account(account_id: str) -> Account:\n    return account_repository.get_closable(account_id) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def close_account(account_id: str) -> None:\n    account = load_closable_account(account_id)\n    archive_account(account)\n\ndef load_closable_account(account_id: str) -> Account:\n    return account_repository.get_closable(account_id)", "typescript": "async function closeAccount(id: string): Promise<void> {\n  const account = await loadClosableAccount(id);\n  await archiveAccount(account);\n}\n\nfunction loadClosableAccount(id: string): Promise<Account> {\n  return accountRepository.getClosable(id);\n}"}, "id": "CC-038", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to stepdown rule: Order functions so high-level behavior leads readers down into details. Search terms that should match this issue include stepdown rule, function smell, single responsibility, small function, function design.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Stepdown Rule", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where order functions so high-level behavior leads readers down into details. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["switch statements", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-039 Switch Statements\nTopic: Functions\nAliases: switch statements, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to switch statements: Move repeated branching behind one named polymorphic or dispatch boundary. Search terms that should match this issue include switch statements, function smell, single responsibility, small function, function design.\nUse when: Use this pattern when planning or reviewing code where move repeated branching behind one named polymorphic or dispatch boundary. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nconst handlers: Record<OrderType, (order: Order) => Promise<void>> = {\n  market: submitMarketOrder,\n  limit: submitLimitOrder,\n};\n\nawait handlers[order.type](order);\nGood Python:\nhandlers: dict[OrderType, Callable[[Order], None]] = {\n    OrderType.MARKET: submit_market_order,\n    OrderType.LIMIT: submit_limit_order,\n}\n\nhandlers[order.type](order)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-039: Switch Statements. Topic: Functions. Rule family: functions. Aliases and smell terms: switch statements, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to switch statements: Move repeated branching behind one named polymorphic or dispatch boundary. Search terms that should match this issue include switch statements, function smell, single responsibility, small function, function design. Use when: Use this pattern when planning or reviewing code where move repeated branching behind one named polymorphic or dispatch boundary. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: const handlers: Record<OrderType, (order: Order) => Promise<void>> = {\n  market: submitMarketOrder,\n  limit: submitLimitOrder,\n};\n\nawait handlers[order.type](order); Good Python example: handlers: dict[OrderType, Callable[[Order], None]] = {\n    OrderType.MARKET: submit_market_order,\n    OrderType.LIMIT: submit_limit_order,\n}\n\nhandlers[order.type](order) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "handlers: dict[OrderType, Callable[[Order], None]] = {\n    OrderType.MARKET: submit_market_order,\n    OrderType.LIMIT: submit_limit_order,\n}\n\nhandlers[order.type](order)", "typescript": "const handlers: Record<OrderType, (order: Order) => Promise<void>> = {\n  market: submitMarketOrder,\n  limit: submitLimitOrder,\n};\n\nawait handlers[order.type](order);"}, "id": "CC-039", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to switch statements: Move repeated branching behind one named polymorphic or dispatch boundary. Search terms that should match this issue include switch statements, function smell, single responsibility, small function, function design.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Switch Statements", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where move repeated branching behind one named polymorphic or dispatch boundary. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["use descriptive function names", "use descriptive", "function names", "naming smell", "identifier name", "semantic naming", "readable name", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-040 Use Descriptive Function Names\nTopic: Functions\nAliases: use descriptive function names, use descriptive, function names, naming smell, identifier name, semantic naming, readable name, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to use descriptive function names: Make function names explain the rule at the call site. Search terms that should match this issue include use descriptive function names, use descriptive, function names, naming smell, identifier name.\nUse when: Use this pattern when planning or reviewing code where make function names explain the rule at the call site. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nif (isEligibleForFreeShipping(cart, customer)) {\n  applyFreeShipping(cart);\n}\nGood Python:\nif is_eligible_for_free_shipping(cart, customer):\n    apply_free_shipping(cart)\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-040: Use Descriptive Function Names. Topic: Functions. Rule family: naming. Aliases and smell terms: use descriptive function names, use descriptive, function names, naming smell, identifier name, semantic naming, readable name, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to use descriptive function names: Make function names explain the rule at the call site. Search terms that should match this issue include use descriptive function names, use descriptive, function names, naming smell, identifier name. Use when: Use this pattern when planning or reviewing code where make function names explain the rule at the call site. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: if (isEligibleForFreeShipping(cart, customer)) {\n  applyFreeShipping(cart);\n} Good Python example: if is_eligible_for_free_shipping(cart, customer):\n    apply_free_shipping(cart) Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "if is_eligible_for_free_shipping(cart, customer):\n    apply_free_shipping(cart)", "typescript": "if (isEligibleForFreeShipping(cart, customer)) {\n  applyFreeShipping(cart);\n}"}, "id": "CC-040", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to use descriptive function names: Make function names explain the rule at the call site. Search terms that should match this issue include use descriptive function names, use descriptive, function names, naming smell, identifier name.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Use Descriptive Function Names", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where make function names explain the rule at the call site. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["function arguments", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-041 Function Arguments\nTopic: Functions\nAliases: function arguments, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to function arguments: Keep argument lists short and cohesive. Search terms that should match this issue include function arguments, function smell, single responsibility, small function, function design.\nUse when: Use this pattern when planning or reviewing code where keep argument lists short and cohesive. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nfunction scheduleDelivery(orderId: string, window: DeliveryWindow): Promise<void> {\n  return deliveryScheduler.schedule(orderId, window);\n}\nGood Python:\ndef schedule_delivery(order_id: str, window: DeliveryWindow) -> None:\n    delivery_scheduler.schedule(order_id, window)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-041: Function Arguments. Topic: Functions. Rule family: functions. Aliases and smell terms: function arguments, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to function arguments: Keep argument lists short and cohesive. Search terms that should match this issue include function arguments, function smell, single responsibility, small function, function design. Use when: Use this pattern when planning or reviewing code where keep argument lists short and cohesive. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: function scheduleDelivery(orderId: string, window: DeliveryWindow): Promise<void> {\n  return deliveryScheduler.schedule(orderId, window);\n} Good Python example: def schedule_delivery(order_id: str, window: DeliveryWindow) -> None:\n    delivery_scheduler.schedule(order_id, window) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def schedule_delivery(order_id: str, window: DeliveryWindow) -> None:\n    delivery_scheduler.schedule(order_id, window)", "typescript": "function scheduleDelivery(orderId: string, window: DeliveryWindow): Promise<void> {\n  return deliveryScheduler.schedule(orderId, window);\n}"}, "id": "CC-041", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to function arguments: Keep argument lists short and cohesive. Search terms that should match this issue include function arguments, function smell, single responsibility, small function, function design.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Function Arguments", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where keep argument lists short and cohesive. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["common monadic forms", "common monadic", "monadic forms", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-042 Common Monadic Forms\nTopic: Functions\nAliases: common monadic forms, common monadic, monadic forms, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to common monadic forms: Use one-argument functions for clear transformations or questions. Search terms that should match this issue include common monadic forms, common monadic, monadic forms, function smell, single responsibility.\nUse when: Use this pattern when planning or reviewing code where use one-argument functions for clear transformations or questions. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nconst normalizedEmail = normalizeEmail(input.email);\nGood Python:\nnormalized_email = normalize_email(payload['email'])\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-042: Common Monadic Forms. Topic: Functions. Rule family: functions. Aliases and smell terms: common monadic forms, common monadic, monadic forms, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to common monadic forms: Use one-argument functions for clear transformations or questions. Search terms that should match this issue include common monadic forms, common monadic, monadic forms, function smell, single responsibility. Use when: Use this pattern when planning or reviewing code where use one-argument functions for clear transformations or questions. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: const normalizedEmail = normalizeEmail(input.email); Good Python example: normalized_email = normalize_email(payload['email']) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "normalized_email = normalize_email(payload['email'])", "typescript": "const normalizedEmail = normalizeEmail(input.email);"}, "id": "CC-042", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to common monadic forms: Use one-argument functions for clear transformations or questions. Search terms that should match this issue include common monadic forms, common monadic, monadic forms, function smell, single responsibility.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Common Monadic Forms", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where use one-argument functions for clear transformations or questions. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["flag arguments", "function smell", "single responsibility", "small function", "function design", "flag argument", "boolean parameter", "selector argument", "boolean mode", "functions", "clean code", "code smell"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "send_invoice(invoice, reminder=True)", "typescript": "sendInvoice(invoice, true);"}, "display_text": "CC-043 Flag Arguments\nTopic: Functions\nAliases: flag arguments, function smell, single responsibility, small function, function design, flag argument, boolean parameter, selector argument, boolean mode, functions, clean code, code smell\nProblem: Code has a clean-code risk related to flag arguments: Replace boolean mode switches with separate intention-revealing functions. Search terms that should match this issue include flag arguments, function smell, single responsibility, small function, function design.\nUse when: Use this pattern when planning or reviewing code where replace boolean mode switches with separate intention-revealing functions. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nsendInvoiceEmail(invoice);\nsendInvoiceReminder(invoice);\nGood Python:\nsend_invoice_email(invoice)\nsend_invoice_reminder(invoice)\nBad TypeScript:\nsendInvoice(invoice, true);\nBad Python:\nsend_invoice(invoice, reminder=True)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-043: Flag Arguments. Topic: Functions. Rule family: functions. Aliases and smell terms: flag arguments, function smell, single responsibility, small function, function design, flag argument, boolean parameter, selector argument, boolean mode, functions, clean code, code smell. Problem: Code has a clean-code risk related to flag arguments: Replace boolean mode switches with separate intention-revealing functions. Search terms that should match this issue include flag arguments, function smell, single responsibility, small function, function design. Use when: Use this pattern when planning or reviewing code where replace boolean mode switches with separate intention-revealing functions. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: sendInvoiceEmail(invoice);\nsendInvoiceReminder(invoice); Good Python example: send_invoice_email(invoice)\nsend_invoice_reminder(invoice) Bad TypeScript example: sendInvoice(invoice, true); Bad Python example: send_invoice(invoice, reminder=True)", "good_examples": {"python": "send_invoice_email(invoice)\nsend_invoice_reminder(invoice)", "typescript": "sendInvoiceEmail(invoice);\nsendInvoiceReminder(invoice);"}, "id": "CC-043", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to flag arguments: Replace boolean mode switches with separate intention-revealing functions. Search terms that should match this issue include flag arguments, function smell, single responsibility, small function, function design.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Flag Arguments", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where replace boolean mode switches with separate intention-revealing functions. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["dyadic functions", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-044 Dyadic Functions\nTopic: Functions\nAliases: dyadic functions, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to dyadic functions: Use two-argument functions only when the relationship is natural and clear. Search terms that should match this issue include dyadic functions, function smell, single responsibility, small function, function design.\nUse when: Use this pattern when planning or reviewing code where use two-argument functions only when the relationship is natural and clear. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nconst distance = distanceBetween(origin, destination);\nGood Python:\ndistance = distance_between(origin, destination)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-044: Dyadic Functions. Topic: Functions. Rule family: functions. Aliases and smell terms: dyadic functions, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to dyadic functions: Use two-argument functions only when the relationship is natural and clear. Search terms that should match this issue include dyadic functions, function smell, single responsibility, small function, function design. Use when: Use this pattern when planning or reviewing code where use two-argument functions only when the relationship is natural and clear. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: const distance = distanceBetween(origin, destination); Good Python example: distance = distance_between(origin, destination) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "distance = distance_between(origin, destination)", "typescript": "const distance = distanceBetween(origin, destination);"}, "id": "CC-044", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to dyadic functions: Use two-argument functions only when the relationship is natural and clear. Search terms that should match this issue include dyadic functions, function smell, single responsibility, small function, function design.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Dyadic Functions", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where use two-argument functions only when the relationship is natural and clear. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["triads", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-045 Triads\nTopic: Functions\nAliases: triads, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to triads: Wrap three related values in a named object when they form a concept. Search terms that should match this issue include triads, function smell, single responsibility, small function, function design.\nUse when: Use this pattern when planning or reviewing code where wrap three related values in a named object when they form a concept. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nconst window = new DeliveryWindow(startAt, endAt, timezone);\nscheduleDelivery(orderId, window);\nGood Python:\nwindow = DeliveryWindow(starts_at, ends_at, timezone)\nschedule_delivery(order_id, window)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-045: Triads. Topic: Functions. Rule family: functions. Aliases and smell terms: triads, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to triads: Wrap three related values in a named object when they form a concept. Search terms that should match this issue include triads, function smell, single responsibility, small function, function design. Use when: Use this pattern when planning or reviewing code where wrap three related values in a named object when they form a concept. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: const window = new DeliveryWindow(startAt, endAt, timezone);\nscheduleDelivery(orderId, window); Good Python example: window = DeliveryWindow(starts_at, ends_at, timezone)\nschedule_delivery(order_id, window) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "window = DeliveryWindow(starts_at, ends_at, timezone)\nschedule_delivery(order_id, window)", "typescript": "const window = new DeliveryWindow(startAt, endAt, timezone);\nscheduleDelivery(orderId, window);"}, "id": "CC-045", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to triads: Wrap three related values in a named object when they form a concept. Search terms that should match this issue include triads, function smell, single responsibility, small function, function design.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Triads", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where wrap three related values in a named object when they form a concept. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["argument objects", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-046 Argument Objects\nTopic: Functions\nAliases: argument objects, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to argument objects: Name cohesive parameter groups as value objects. Search terms that should match this issue include argument objects, function smell, single responsibility, small function, function design.\nUse when: Use this pattern when planning or reviewing code where name cohesive parameter groups as value objects. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\ntype DateRange = { startsAt: Date; endsAt: Date };\nloadStatements(accountId, range);\nGood Python:\n@dataclass(frozen=True)\nclass DateRange:\n    starts_at: datetime\n    ends_at: datetime\n\nload_statements(account_id, range)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-046: Argument Objects. Topic: Functions. Rule family: functions. Aliases and smell terms: argument objects, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to argument objects: Name cohesive parameter groups as value objects. Search terms that should match this issue include argument objects, function smell, single responsibility, small function, function design. Use when: Use this pattern when planning or reviewing code where name cohesive parameter groups as value objects. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: type DateRange = { startsAt: Date; endsAt: Date };\nloadStatements(accountId, range); Good Python example: @dataclass(frozen=True)\nclass DateRange:\n    starts_at: datetime\n    ends_at: datetime\n\nload_statements(account_id, range) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "@dataclass(frozen=True)\nclass DateRange:\n    starts_at: datetime\n    ends_at: datetime\n\nload_statements(account_id, range)", "typescript": "type DateRange = { startsAt: Date; endsAt: Date };\nloadStatements(accountId, range);"}, "id": "CC-046", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to argument objects: Name cohesive parameter groups as value objects. Search terms that should match this issue include argument objects, function smell, single responsibility, small function, function design.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Argument Objects", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where name cohesive parameter groups as value objects. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["argument lists", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-047 Argument Lists\nTopic: Functions\nAliases: argument lists, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to argument lists: Use variadic arguments only for homogeneous values with a clear meaning. Search terms that should match this issue include argument lists, function smell, single responsibility, small function, function design.\nUse when: Use this pattern when planning or reviewing code where use variadic arguments only for homogeneous values with a clear meaning. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nfunction combineTags(...tags: string[]): string[] {\n  return [...new Set(tags.map(normalizeTag))];\n}\nGood Python:\ndef combine_tags(*tags: str) -> list[str]:\n    return list({normalize_tag(tag) for tag in tags})\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-047: Argument Lists. Topic: Functions. Rule family: functions. Aliases and smell terms: argument lists, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to argument lists: Use variadic arguments only for homogeneous values with a clear meaning. Search terms that should match this issue include argument lists, function smell, single responsibility, small function, function design. Use when: Use this pattern when planning or reviewing code where use variadic arguments only for homogeneous values with a clear meaning. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: function combineTags(...tags: string[]): string[] {\n  return [...new Set(tags.map(normalizeTag))];\n} Good Python example: def combine_tags(*tags: str) -> list[str]:\n    return list({normalize_tag(tag) for tag in tags}) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def combine_tags(*tags: str) -> list[str]:\n    return list({normalize_tag(tag) for tag in tags})", "typescript": "function combineTags(...tags: string[]): string[] {\n  return [...new Set(tags.map(normalizeTag))];\n}"}, "id": "CC-047", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to argument lists: Use variadic arguments only for homogeneous values with a clear meaning. Search terms that should match this issue include argument lists, function smell, single responsibility, small function, function design.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Argument Lists", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where use variadic arguments only for homogeneous values with a clear meaning. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["verbs and keywords", "verbs and", "and keywords", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-048 Verbs And Keywords\nTopic: Functions\nAliases: verbs and keywords, verbs and, and keywords, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to verbs and keywords: Choose names that pair clearly with their arguments. Search terms that should match this issue include verbs and keywords, verbs and, and keywords, function smell, single responsibility.\nUse when: Use this pattern when planning or reviewing code where choose names that pair clearly with their arguments. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nassertAccountCanTransfer(account, amount);\nGood Python:\nassert_account_can_transfer(account, amount)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-048: Verbs And Keywords. Topic: Functions. Rule family: functions. Aliases and smell terms: verbs and keywords, verbs and, and keywords, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to verbs and keywords: Choose names that pair clearly with their arguments. Search terms that should match this issue include verbs and keywords, verbs and, and keywords, function smell, single responsibility. Use when: Use this pattern when planning or reviewing code where choose names that pair clearly with their arguments. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: assertAccountCanTransfer(account, amount); Good Python example: assert_account_can_transfer(account, amount) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "assert_account_can_transfer(account, amount)", "typescript": "assertAccountCanTransfer(account, amount);"}, "id": "CC-048", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to verbs and keywords: Choose names that pair clearly with their arguments. Search terms that should match this issue include verbs and keywords, verbs and, and keywords, function smell, single responsibility.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Verbs And Keywords", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where choose names that pair clearly with their arguments. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["have no side effects", "have no", "side effects", "function smell", "single responsibility", "small function", "function design", "hidden side effect", "mutation", "command query separation", "unexpected write", "functions"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-049 Have No Side Effects\nTopic: Functions\nAliases: have no side effects, have no, side effects, function smell, single responsibility, small function, function design, hidden side effect, mutation, command query separation, unexpected write, functions\nProblem: Code has a clean-code risk related to have no side effects: Do not hide writes or I/O inside functions that look like pure calculations. Search terms that should match this issue include have no side effects, have no, side effects, function smell, single responsibility.\nUse when: Use this pattern when planning or reviewing code where do not hide writes or I/O inside functions that look like pure calculations. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nfunction calculateReceipt(order: Order): Receipt {\n  return Receipt.from(order);\n}\nGood Python:\ndef calculate_receipt(order: Order) -> Receipt:\n    return Receipt.from_order(order)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-049: Have No Side Effects. Topic: Functions. Rule family: functions. Aliases and smell terms: have no side effects, have no, side effects, function smell, single responsibility, small function, function design, hidden side effect, mutation, command query separation, unexpected write, functions. Problem: Code has a clean-code risk related to have no side effects: Do not hide writes or I/O inside functions that look like pure calculations. Search terms that should match this issue include have no side effects, have no, side effects, function smell, single responsibility. Use when: Use this pattern when planning or reviewing code where do not hide writes or I/O inside functions that look like pure calculations. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: function calculateReceipt(order: Order): Receipt {\n  return Receipt.from(order);\n} Good Python example: def calculate_receipt(order: Order) -> Receipt:\n    return Receipt.from_order(order) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def calculate_receipt(order: Order) -> Receipt:\n    return Receipt.from_order(order)", "typescript": "function calculateReceipt(order: Order): Receipt {\n  return Receipt.from(order);\n}"}, "id": "CC-049", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to have no side effects: Do not hide writes or I/O inside functions that look like pure calculations. Search terms that should match this issue include have no side effects, have no, side effects, function smell, single responsibility.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Have No Side Effects", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where do not hide writes or I/O inside functions that look like pure calculations. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["output arguments", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-050 Output Arguments\nTopic: Functions\nAliases: output arguments, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to output arguments: Return new values instead of mutating arguments for hidden output. Search terms that should match this issue include output arguments, function smell, single responsibility, small function, function design.\nUse when: Use this pattern when planning or reviewing code where return new values instead of mutating arguments for hidden output. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nconst enrichedOrder = addTaxDetails(order, taxRate);\nGood Python:\nenriched_order = add_tax_details(order, tax_rate)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-050: Output Arguments. Topic: Functions. Rule family: functions. Aliases and smell terms: output arguments, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to output arguments: Return new values instead of mutating arguments for hidden output. Search terms that should match this issue include output arguments, function smell, single responsibility, small function, function design. Use when: Use this pattern when planning or reviewing code where return new values instead of mutating arguments for hidden output. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: const enrichedOrder = addTaxDetails(order, taxRate); Good Python example: enriched_order = add_tax_details(order, tax_rate) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "enriched_order = add_tax_details(order, tax_rate)", "typescript": "const enrichedOrder = addTaxDetails(order, taxRate);"}, "id": "CC-050", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to output arguments: Return new values instead of mutating arguments for hidden output. Search terms that should match this issue include output arguments, function smell, single responsibility, small function, function design.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Output Arguments", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where return new values instead of mutating arguments for hidden output. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["command query separation", "command query", "query separation", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-051 Command Query Separation\nTopic: Functions\nAliases: command query separation, command query, query separation, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to command query separation: Ask questions and perform commands in separate calls. Search terms that should match this issue include command query separation, command query, query separation, function smell, single responsibility.\nUse when: Use this pattern when planning or reviewing code where ask questions and perform commands in separate calls. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nif (!cartHasItem(cart, sku)) {\n  addItemToCart(cart, sku);\n}\nGood Python:\nif not cart_has_item(cart, sku):\n    add_item_to_cart(cart, sku)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-051: Command Query Separation. Topic: Functions. Rule family: functions. Aliases and smell terms: command query separation, command query, query separation, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to command query separation: Ask questions and perform commands in separate calls. Search terms that should match this issue include command query separation, command query, query separation, function smell, single responsibility. Use when: Use this pattern when planning or reviewing code where ask questions and perform commands in separate calls. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: if (!cartHasItem(cart, sku)) {\n  addItemToCart(cart, sku);\n} Good Python example: if not cart_has_item(cart, sku):\n    add_item_to_cart(cart, sku) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "if not cart_has_item(cart, sku):\n    add_item_to_cart(cart, sku)", "typescript": "if (!cartHasItem(cart, sku)) {\n  addItemToCart(cart, sku);\n}"}, "id": "CC-051", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to command query separation: Ask questions and perform commands in separate calls. Search terms that should match this issue include command query separation, command query, query separation, function smell, single responsibility.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Command Query Separation", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where ask questions and perform commands in separate calls. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["prefer exceptions to returning error codes", "prefer exceptions", "error codes", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-052 Prefer Exceptions To Returning Error Codes\nTopic: Functions\nAliases: prefer exceptions to returning error codes, prefer exceptions, error codes, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to prefer exceptions to returning error codes: Use explicit failures so callers cannot ignore errors accidentally. Search terms that should match this issue include prefer exceptions to returning error codes, prefer exceptions, error codes, function smell, single responsibility.\nUse when: Use this pattern when planning or reviewing code where use explicit failures so callers cannot ignore errors accidentally. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nif (!invoice) {\n  throw new InvoiceNotFoundError(invoiceId);\n}\nreturn invoice;\nGood Python:\nif invoice is None:\n    raise InvoiceNotFoundError(invoice_id)\nreturn invoice\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-052: Prefer Exceptions To Returning Error Codes. Topic: Functions. Rule family: functions. Aliases and smell terms: prefer exceptions to returning error codes, prefer exceptions, error codes, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to prefer exceptions to returning error codes: Use explicit failures so callers cannot ignore errors accidentally. Search terms that should match this issue include prefer exceptions to returning error codes, prefer exceptions, error codes, function smell, single responsibility. Use when: Use this pattern when planning or reviewing code where use explicit failures so callers cannot ignore errors accidentally. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: if (!invoice) {\n  throw new InvoiceNotFoundError(invoiceId);\n}\nreturn invoice; Good Python example: if invoice is None:\n    raise InvoiceNotFoundError(invoice_id)\nreturn invoice Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "if invoice is None:\n    raise InvoiceNotFoundError(invoice_id)\nreturn invoice", "typescript": "if (!invoice) {\n  throw new InvoiceNotFoundError(invoiceId);\n}\nreturn invoice;"}, "id": "CC-052", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to prefer exceptions to returning error codes: Use explicit failures so callers cannot ignore errors accidentally. Search terms that should match this issue include prefer exceptions to returning error codes, prefer exceptions, error codes, function smell, single responsibility.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Prefer Exceptions To Returning Error Codes", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where use explicit failures so callers cannot ignore errors accidentally. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["extract try/catch blocks", "extract try catch blocks", "extract try", "catch blocks", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-053 Extract Try/Catch Blocks\nTopic: Functions\nAliases: extract try/catch blocks, extract try catch blocks, extract try, catch blocks, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to extract try/catch blocks: Keep error translation separate from the main behavior. Search terms that should match this issue include extract try/catch blocks, extract try catch blocks, extract try, catch blocks, function smell.\nUse when: Use this pattern when planning or reviewing code where keep error translation separate from the main behavior. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\ntry {\n  return await loadCustomerView(id);\n} catch (error) {\n  throw mapCustomerError(error, id);\n}\nGood Python:\ntry:\n    return load_customer_view(customer_id)\nexcept RepositoryError as error:\n    raise map_customer_error(error, customer_id) from error\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-053: Extract Try/Catch Blocks. Topic: Functions. Rule family: functions. Aliases and smell terms: extract try/catch blocks, extract try catch blocks, extract try, catch blocks, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to extract try/catch blocks: Keep error translation separate from the main behavior. Search terms that should match this issue include extract try/catch blocks, extract try catch blocks, extract try, catch blocks, function smell. Use when: Use this pattern when planning or reviewing code where keep error translation separate from the main behavior. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: try {\n  return await loadCustomerView(id);\n} catch (error) {\n  throw mapCustomerError(error, id);\n} Good Python example: try:\n    return load_customer_view(customer_id)\nexcept RepositoryError as error:\n    raise map_customer_error(error, customer_id) from error Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "try:\n    return load_customer_view(customer_id)\nexcept RepositoryError as error:\n    raise map_customer_error(error, customer_id) from error", "typescript": "try {\n  return await loadCustomerView(id);\n} catch (error) {\n  throw mapCustomerError(error, id);\n}"}, "id": "CC-053", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to extract try/catch blocks: Keep error translation separate from the main behavior. Search terms that should match this issue include extract try/catch blocks, extract try catch blocks, extract try, catch blocks, function smell.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Extract Try/Catch Blocks", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where keep error translation separate from the main behavior. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["error handling is one thing", "error handling", "one thing", "function smell", "single responsibility", "small function", "function design", "do one thing", "mixed responsibility", "function cohesion", "functions", "clean code"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "def submit_order(payload):\n    validate(payload)\n    db.save(payload)\n    email(payload)", "typescript": "async function submitOrder(input) { validate(input); await db.save(input); await email(input); }"}, "display_text": "CC-054 Error Handling Is One Thing\nTopic: Functions\nAliases: error handling is one thing, error handling, one thing, function smell, single responsibility, small function, function design, do one thing, mixed responsibility, function cohesion, functions, clean code\nProblem: Code has a clean-code risk related to error handling is one thing: Do not mix fallback, logging, and business decisions in the same catch block. Search terms that should match this issue include error handling is one thing, error handling, one thing, function smell, single responsibility.\nUse when: Use this pattern when planning or reviewing code where do not mix fallback, logging, and business decisions in the same catch block. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nasync function readSettings(): Promise<Settings> {\n  try {\n    return await settingsStore.read();\n  } catch (error) {\n    return defaultSettingsFor(error);\n  }\n}\nGood Python:\ndef read_settings() -> Settings:\n    try:\n        return settings_store.read()\n    except SettingsStoreError as error:\n        return default_settings_for(error)\nBad TypeScript:\nasync function submitOrder(input) { validate(input); await db.save(input); await email(input); }\nBad Python:\ndef submit_order(payload):\n    validate(payload)\n    db.save(payload)\n    email(payload)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-054: Error Handling Is One Thing. Topic: Functions. Rule family: functions. Aliases and smell terms: error handling is one thing, error handling, one thing, function smell, single responsibility, small function, function design, do one thing, mixed responsibility, function cohesion, functions, clean code. Problem: Code has a clean-code risk related to error handling is one thing: Do not mix fallback, logging, and business decisions in the same catch block. Search terms that should match this issue include error handling is one thing, error handling, one thing, function smell, single responsibility. Use when: Use this pattern when planning or reviewing code where do not mix fallback, logging, and business decisions in the same catch block. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: async function readSettings(): Promise<Settings> {\n  try {\n    return await settingsStore.read();\n  } catch (error) {\n    return defaultSettingsFor(error);\n  }\n} Good Python example: def read_settings() -> Settings:\n    try:\n        return settings_store.read()\n    except SettingsStoreError as error:\n        return default_settings_for(error) Bad TypeScript example: async function submitOrder(input) { validate(input); await db.save(input); await email(input); } Bad Python example: def submit_order(payload):\n    validate(payload)\n    db.save(payload)\n    email(payload)", "good_examples": {"python": "def read_settings() -> Settings:\n    try:\n        return settings_store.read()\n    except SettingsStoreError as error:\n        return default_settings_for(error)", "typescript": "async function readSettings(): Promise<Settings> {\n  try {\n    return await settingsStore.read();\n  } catch (error) {\n    return defaultSettingsFor(error);\n  }\n}"}, "id": "CC-054", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to error handling is one thing: Do not mix fallback, logging, and business decisions in the same catch block. Search terms that should match this issue include error handling is one thing, error handling, one thing, function smell, single responsibility.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Error Handling Is One Thing", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where do not mix fallback, logging, and business decisions in the same catch block. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["error dependency magnet", "error dependency", "dependency magnet", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-055 Error Dependency Magnet\nTopic: Functions\nAliases: error dependency magnet, error dependency, dependency magnet, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to error dependency magnet: Keep shared error definitions small so unrelated modules do not depend on one bloated error file. Search terms that should match this issue include error dependency magnet, error dependency, dependency magnet, function smell, single responsibility.\nUse when: Use this pattern when planning or reviewing code where keep shared error definitions small so unrelated modules do not depend on one bloated error file. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nexport class PaymentDeclinedError extends Error {\n  constructor(readonly paymentId: string) {\n    super(`Payment declined: ${paymentId}`);\n  }\n}\nGood Python:\nclass PaymentDeclinedError(Exception):\n    def __init__(self, payment_id: str) -> None:\n        super().__init__(f'Payment declined: {payment_id}')\n        self.payment_id = payment_id\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-055: Error Dependency Magnet. Topic: Functions. Rule family: functions. Aliases and smell terms: error dependency magnet, error dependency, dependency magnet, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to error dependency magnet: Keep shared error definitions small so unrelated modules do not depend on one bloated error file. Search terms that should match this issue include error dependency magnet, error dependency, dependency magnet, function smell, single responsibility. Use when: Use this pattern when planning or reviewing code where keep shared error definitions small so unrelated modules do not depend on one bloated error file. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: export class PaymentDeclinedError extends Error {\n  constructor(readonly paymentId: string) {\n    super(`Payment declined: ${paymentId}`);\n  }\n} Good Python example: class PaymentDeclinedError(Exception):\n    def __init__(self, payment_id: str) -> None:\n        super().__init__(f'Payment declined: {payment_id}')\n        self.payment_id = payment_id Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "class PaymentDeclinedError(Exception):\n    def __init__(self, payment_id: str) -> None:\n        super().__init__(f'Payment declined: {payment_id}')\n        self.payment_id = payment_id", "typescript": "export class PaymentDeclinedError extends Error {\n  constructor(readonly paymentId: string) {\n    super(`Payment declined: ${paymentId}`);\n  }\n}"}, "id": "CC-055", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to error dependency magnet: Keep shared error definitions small so unrelated modules do not depend on one bloated error file. Search terms that should match this issue include error dependency magnet, error dependency, dependency magnet, function smell, single responsibility.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Error Dependency Magnet", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where keep shared error definitions small so unrelated modules do not depend on one bloated error file. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["do not repeat yourself", "do not", "repeat yourself", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-056 Do Not Repeat Yourself\nTopic: Functions\nAliases: do not repeat yourself, do not, repeat yourself, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to do not repeat yourself: Extract repeated knowledge into a single named rule. Search terms that should match this issue include do not repeat yourself, do not, repeat yourself, function smell, single responsibility.\nUse when: Use this pattern when planning or reviewing code where extract repeated knowledge into a single named rule. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nfunction isPasswordExpired(changedAt: Date, now: Date): boolean {\n  return daysBetween(changedAt, now) > PASSWORD_EXPIRY_DAYS;\n}\nGood Python:\ndef is_password_expired(changed_at: datetime, now: datetime) -> bool:\n    return days_between(changed_at, now) > PASSWORD_EXPIRY_DAYS\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-056: Do Not Repeat Yourself. Topic: Functions. Rule family: functions. Aliases and smell terms: do not repeat yourself, do not, repeat yourself, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to do not repeat yourself: Extract repeated knowledge into a single named rule. Search terms that should match this issue include do not repeat yourself, do not, repeat yourself, function smell, single responsibility. Use when: Use this pattern when planning or reviewing code where extract repeated knowledge into a single named rule. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: function isPasswordExpired(changedAt: Date, now: Date): boolean {\n  return daysBetween(changedAt, now) > PASSWORD_EXPIRY_DAYS;\n} Good Python example: def is_password_expired(changed_at: datetime, now: datetime) -> bool:\n    return days_between(changed_at, now) > PASSWORD_EXPIRY_DAYS Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def is_password_expired(changed_at: datetime, now: datetime) -> bool:\n    return days_between(changed_at, now) > PASSWORD_EXPIRY_DAYS", "typescript": "function isPasswordExpired(changedAt: Date, now: Date): boolean {\n  return daysBetween(changedAt, now) > PASSWORD_EXPIRY_DAYS;\n}"}, "id": "CC-056", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to do not repeat yourself: Extract repeated knowledge into a single named rule. Search terms that should match this issue include do not repeat yourself, do not, repeat yourself, function smell, single responsibility.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Do Not Repeat Yourself", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where extract repeated knowledge into a single named rule. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["structured programming", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-057 Structured Programming\nTopic: Functions\nAliases: structured programming, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to structured programming: Use simple structured control flow before reaching for jumps, flags, or tangled exits. Search terms that should match this issue include structured programming, function smell, single responsibility, small function, function design.\nUse when: Use this pattern when planning or reviewing code where use simple structured control flow before reaching for jumps, flags, or tangled exits. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nfor (const item of order.items) {\n  validateOrderItem(item);\n}\nGood Python:\nfor item in order.items:\n    validate_order_item(item)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-057: Structured Programming. Topic: Functions. Rule family: functions. Aliases and smell terms: structured programming, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to structured programming: Use simple structured control flow before reaching for jumps, flags, or tangled exits. Search terms that should match this issue include structured programming, function smell, single responsibility, small function, function design. Use when: Use this pattern when planning or reviewing code where use simple structured control flow before reaching for jumps, flags, or tangled exits. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: for (const item of order.items) {\n  validateOrderItem(item);\n} Good Python example: for item in order.items:\n    validate_order_item(item) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "for item in order.items:\n    validate_order_item(item)", "typescript": "for (const item of order.items) {\n  validateOrderItem(item);\n}"}, "id": "CC-057", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to structured programming: Use simple structured control flow before reaching for jumps, flags, or tangled exits. Search terms that should match this issue include structured programming, function smell, single responsibility, small function, function design.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Structured Programming", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where use simple structured control flow before reaching for jumps, flags, or tangled exits. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["how to write functions like this", "how to", "like this", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-058 How To Write Functions Like This\nTopic: Functions\nAliases: how to write functions like this, how to, like this, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to how to write functions like this: Refine functions through repeated extraction, renaming, and testing. Search terms that should match this issue include how to write functions like this, how to, like this, function smell, single responsibility.\nUse when: Use this pattern when planning or reviewing code where refine functions through repeated extraction, renaming, and testing. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nconst order = buildOrder(input);\nvalidateOrder(order);\nawait submitOrder(order);\nGood Python:\norder = build_order(payload)\nvalidate_order(order)\nsubmit_order(order)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-058: How To Write Functions Like This. Topic: Functions. Rule family: functions. Aliases and smell terms: how to write functions like this, how to, like this, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to how to write functions like this: Refine functions through repeated extraction, renaming, and testing. Search terms that should match this issue include how to write functions like this, how to, like this, function smell, single responsibility. Use when: Use this pattern when planning or reviewing code where refine functions through repeated extraction, renaming, and testing. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: const order = buildOrder(input);\nvalidateOrder(order);\nawait submitOrder(order); Good Python example: order = build_order(payload)\nvalidate_order(order)\nsubmit_order(order) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "order = build_order(payload)\nvalidate_order(order)\nsubmit_order(order)", "typescript": "const order = buildOrder(input);\nvalidateOrder(order);\nawait submitOrder(order);"}, "id": "CC-058", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to how to write functions like this: Refine functions through repeated extraction, renaming, and testing. Search terms that should match this issue include how to write functions like this, how to, like this, function smell, single responsibility.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "How To Write Functions Like This", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where refine functions through repeated extraction, renaming, and testing. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["setupteardownincluder", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-059 SetupTeardownIncluder\nTopic: Functions\nAliases: setupteardownincluder, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to setupteardownincluder: Separate setup, execution, and teardown so each phase is understandable. Search terms that should match this issue include setupteardownincluder, function smell, single responsibility, small function, function design.\nUse when: Use this pattern when planning or reviewing code where separate setup, execution, and teardown so each phase is understandable. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nconst server = await startTestServer();\ntry {\n  await runContractTests(server.url);\n} finally {\n  await server.stop();\n}\nGood Python:\nwith start_test_server() as server:\n    run_contract_tests(server.url)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.\nLintability: high", "embedding_text": "Clean code pattern CC-059: SetupTeardownIncluder. Topic: Functions. Rule family: functions. Aliases and smell terms: setupteardownincluder, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to setupteardownincluder: Separate setup, execution, and teardown so each phase is understandable. Search terms that should match this issue include setupteardownincluder, function smell, single responsibility, small function, function design. Use when: Use this pattern when planning or reviewing code where separate setup, execution, and teardown so each phase is understandable. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels.. Good TypeScript example: const server = await startTestServer();\ntry {\n  await runContractTests(server.url);\n} finally {\n  await server.stop();\n} Good Python example: with start_test_server() as server:\n    run_contract_tests(server.url) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "with start_test_server() as server:\n    run_contract_tests(server.url)", "typescript": "const server = await startTestServer();\ntry {\n  await runContractTests(server.url);\n} finally {\n  await server.stop();\n}"}, "id": "CC-059", "lint_candidates": ["Flag excessive length, argument count, flag arguments, hidden mutation, and mixed abstraction levels."], "lintability": "high", "problem": "Code has a clean-code risk related to setupteardownincluder: Separate setup, execution, and teardown so each phase is understandable. Search terms that should match this issue include setupteardownincluder, function smell, single responsibility, small function, function design.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "SetupTeardownIncluder", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where separate setup, execution, and teardown so each phase is understandable. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["comments do not make up for bad code", "comments do", "bad code", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-060 Comments Do Not Make Up For Bad Code\nTopic: Comments\nAliases: comments do not make up for bad code, comments do, bad code, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to comments do not make up for bad code: Improve the code structure before adding a comment to explain confusing logic. Search terms that should match this issue include comments do not make up for bad code, comments do, bad code, comment smell, stale comment.\nUse when: Use this pattern when planning or reviewing code where improve the code structure before adding a comment to explain confusing logic. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nconst isPriorityRefund = refund.amount.greaterThan(PRIORITY_REFUND_AMOUNT);\nif (isPriorityRefund) escalateRefund(refund);\nGood Python:\nis_priority_refund = refund.amount > PRIORITY_REFUND_AMOUNT\nif is_priority_refund:\n    escalate_refund(refund)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Flag comments before complex boolean expressions.\nLintability: high", "embedding_text": "Clean code pattern CC-060: Comments Do Not Make Up For Bad Code. Topic: Comments. Rule family: comments. Aliases and smell terms: comments do not make up for bad code, comments do, bad code, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to comments do not make up for bad code: Improve the code structure before adding a comment to explain confusing logic. Search terms that should match this issue include comments do not make up for bad code, comments do, bad code, comment smell, stale comment. Use when: Use this pattern when planning or reviewing code where improve the code structure before adding a comment to explain confusing logic. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Flag comments before complex boolean expressions.. Good TypeScript example: const isPriorityRefund = refund.amount.greaterThan(PRIORITY_REFUND_AMOUNT);\nif (isPriorityRefund) escalateRefund(refund); Good Python example: is_priority_refund = refund.amount > PRIORITY_REFUND_AMOUNT\nif is_priority_refund:\n    escalate_refund(refund) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "is_priority_refund = refund.amount > PRIORITY_REFUND_AMOUNT\nif is_priority_refund:\n    escalate_refund(refund)", "typescript": "const isPriorityRefund = refund.amount.greaterThan(PRIORITY_REFUND_AMOUNT);\nif (isPriorityRefund) escalateRefund(refund);"}, "id": "CC-060", "lint_candidates": ["Flag comments before complex boolean expressions."], "lintability": "high", "problem": "Code has a clean-code risk related to comments do not make up for bad code: Improve the code structure before adding a comment to explain confusing logic. Search terms that should match this issue include comments do not make up for bad code, comments do, bad code, comment smell, stale comment.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Comments Do Not Make Up For Bad Code", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where improve the code structure before adding a comment to explain confusing logic. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["explain yourself in code", "explain yourself", "in code", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-061 Explain Yourself In Code\nTopic: Comments\nAliases: explain yourself in code, explain yourself, in code, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to explain yourself in code: Use named helpers and variables to explain intent directly in executable code. Search terms that should match this issue include explain yourself in code, explain yourself, in code, comment smell, stale comment.\nUse when: Use this pattern when planning or reviewing code where use named helpers and variables to explain intent directly in executable code. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nif (isWithinGracePeriod(invoice, now)) skipLateFee(invoice);\nGood Python:\nif is_within_grace_period(invoice, now):\n    skip_late_fee(invoice)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Suggest extracting named predicates for complex conditions.\nLintability: high", "embedding_text": "Clean code pattern CC-061: Explain Yourself In Code. Topic: Comments. Rule family: comments. Aliases and smell terms: explain yourself in code, explain yourself, in code, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to explain yourself in code: Use named helpers and variables to explain intent directly in executable code. Search terms that should match this issue include explain yourself in code, explain yourself, in code, comment smell, stale comment. Use when: Use this pattern when planning or reviewing code where use named helpers and variables to explain intent directly in executable code. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Suggest extracting named predicates for complex conditions.. Good TypeScript example: if (isWithinGracePeriod(invoice, now)) skipLateFee(invoice); Good Python example: if is_within_grace_period(invoice, now):\n    skip_late_fee(invoice) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "if is_within_grace_period(invoice, now):\n    skip_late_fee(invoice)", "typescript": "if (isWithinGracePeriod(invoice, now)) skipLateFee(invoice);"}, "id": "CC-061", "lint_candidates": ["Suggest extracting named predicates for complex conditions."], "lintability": "high", "problem": "Code has a clean-code risk related to explain yourself in code: Use named helpers and variables to explain intent directly in executable code. Search terms that should match this issue include explain yourself in code, explain yourself, in code, comment smell, stale comment.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Explain Yourself In Code", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where use named helpers and variables to explain intent directly in executable code. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["good comments", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-062 Good Comments\nTopic: Comments\nAliases: good comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to good comments: Reserve comments for non-obvious context that code cannot express well. Search terms that should match this issue include good comments, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where reserve comments for non-obvious context that code cannot express well. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\n// Provider clocks can drift, so submit one minute behind our observed time.\nconst submittedAt = subtractMinutes(now, 1);\nGood Python:\n# Provider clocks can drift, so submit one minute behind our observed time.\nsubmitted_at = now - timedelta(minutes=1)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Allow comments that explain why, constraints, or external behavior.\nLintability: low", "embedding_text": "Clean code pattern CC-062: Good Comments. Topic: Comments. Rule family: comments. Aliases and smell terms: good comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to good comments: Reserve comments for non-obvious context that code cannot express well. Search terms that should match this issue include good comments, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where reserve comments for non-obvious context that code cannot express well. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Allow comments that explain why, constraints, or external behavior.. Good TypeScript example: // Provider clocks can drift, so submit one minute behind our observed time.\nconst submittedAt = subtractMinutes(now, 1); Good Python example: # Provider clocks can drift, so submit one minute behind our observed time.\nsubmitted_at = now - timedelta(minutes=1) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "# Provider clocks can drift, so submit one minute behind our observed time.\nsubmitted_at = now - timedelta(minutes=1)", "typescript": "// Provider clocks can drift, so submit one minute behind our observed time.\nconst submittedAt = subtractMinutes(now, 1);"}, "id": "CC-062", "lint_candidates": ["Allow comments that explain why, constraints, or external behavior."], "lintability": "low", "problem": "Code has a clean-code risk related to good comments: Reserve comments for non-obvious context that code cannot express well. Search terms that should match this issue include good comments, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Good Comments", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where reserve comments for non-obvious context that code cannot express well. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["legal comments", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-063 Legal Comments\nTopic: Comments\nAliases: legal comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to legal comments: Keep required legal notices brief and point to the canonical license when possible. Search terms that should match this issue include legal comments, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where keep required legal notices brief and point to the canonical license when possible. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\n// SPDX-License-Identifier: MIT\nexport function parseAmount(value: string): Money {\n  return Money.parse(value);\n}\nGood Python:\n# SPDX-License-Identifier: MIT\ndef parse_amount(value: str) -> Money:\n    return Money.parse(value)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Enforce SPDX headers instead of long pasted licenses.\nLintability: high", "embedding_text": "Clean code pattern CC-063: Legal Comments. Topic: Comments. Rule family: comments. Aliases and smell terms: legal comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to legal comments: Keep required legal notices brief and point to the canonical license when possible. Search terms that should match this issue include legal comments, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where keep required legal notices brief and point to the canonical license when possible. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Enforce SPDX headers instead of long pasted licenses.. Good TypeScript example: // SPDX-License-Identifier: MIT\nexport function parseAmount(value: string): Money {\n  return Money.parse(value);\n} Good Python example: # SPDX-License-Identifier: MIT\ndef parse_amount(value: str) -> Money:\n    return Money.parse(value) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "# SPDX-License-Identifier: MIT\ndef parse_amount(value: str) -> Money:\n    return Money.parse(value)", "typescript": "// SPDX-License-Identifier: MIT\nexport function parseAmount(value: string): Money {\n  return Money.parse(value);\n}"}, "id": "CC-063", "lint_candidates": ["Enforce SPDX headers instead of long pasted licenses."], "lintability": "high", "problem": "Code has a clean-code risk related to legal comments: Keep required legal notices brief and point to the canonical license when possible. Search terms that should match this issue include legal comments, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Legal Comments", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where keep required legal notices brief and point to the canonical license when possible. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["informative comments", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-064 Informative Comments\nTopic: Comments\nAliases: informative comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to informative comments: Use a short comment when it names a format or convention that is not obvious locally. Search terms that should match this issue include informative comments, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where use a short comment when it names a format or convention that is not obvious locally. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\n// External report format: YYYYMMDD-accountId.csv\nconst reportName = `${formatDate(day)}-${accountId}.csv`;\nGood Python:\n# External report format: YYYYMMDD-account_id.csv\nreport_name = f'{format_date(day)}-{account_id}.csv'\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Allow comments documenting external wire/file formats.\nLintability: low", "embedding_text": "Clean code pattern CC-064: Informative Comments. Topic: Comments. Rule family: comments. Aliases and smell terms: informative comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to informative comments: Use a short comment when it names a format or convention that is not obvious locally. Search terms that should match this issue include informative comments, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where use a short comment when it names a format or convention that is not obvious locally. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Allow comments documenting external wire/file formats.. Good TypeScript example: // External report format: YYYYMMDD-accountId.csv\nconst reportName = `${formatDate(day)}-${accountId}.csv`; Good Python example: # External report format: YYYYMMDD-account_id.csv\nreport_name = f'{format_date(day)}-{account_id}.csv' Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "# External report format: YYYYMMDD-account_id.csv\nreport_name = f'{format_date(day)}-{account_id}.csv'", "typescript": "// External report format: YYYYMMDD-accountId.csv\nconst reportName = `${formatDate(day)}-${accountId}.csv`;"}, "id": "CC-064", "lint_candidates": ["Allow comments documenting external wire/file formats."], "lintability": "low", "problem": "Code has a clean-code risk related to informative comments: Use a short comment when it names a format or convention that is not obvious locally. Search terms that should match this issue include informative comments, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Informative Comments", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where use a short comment when it names a format or convention that is not obvious locally. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["explanation of intent", "explanation of", "of intent", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-065 Explanation Of Intent\nTopic: Comments\nAliases: explanation of intent, explanation of, of intent, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to explanation of intent: Explain why an unusual choice is intentional. Search terms that should match this issue include explanation of intent, explanation of, of intent, comment smell, stale comment.\nUse when: Use this pattern when planning or reviewing code where explain why an unusual choice is intentional. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\n// Prefer a stale cached quote over blocking checkout during provider outages.\nreturn cachedQuote ?? await quoteProvider.fetch(pair);\nGood Python:\n# Prefer a stale cached quote over blocking checkout during provider outages.\nreturn cached_quote or quote_provider.fetch(pair)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Allow comments containing tradeoff terms such as prefer, because, or during.\nLintability: low", "embedding_text": "Clean code pattern CC-065: Explanation Of Intent. Topic: Comments. Rule family: comments. Aliases and smell terms: explanation of intent, explanation of, of intent, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to explanation of intent: Explain why an unusual choice is intentional. Search terms that should match this issue include explanation of intent, explanation of, of intent, comment smell, stale comment. Use when: Use this pattern when planning or reviewing code where explain why an unusual choice is intentional. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Allow comments containing tradeoff terms such as prefer, because, or during.. Good TypeScript example: // Prefer a stale cached quote over blocking checkout during provider outages.\nreturn cachedQuote ?? await quoteProvider.fetch(pair); Good Python example: # Prefer a stale cached quote over blocking checkout during provider outages.\nreturn cached_quote or quote_provider.fetch(pair) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "# Prefer a stale cached quote over blocking checkout during provider outages.\nreturn cached_quote or quote_provider.fetch(pair)", "typescript": "// Prefer a stale cached quote over blocking checkout during provider outages.\nreturn cachedQuote ?? await quoteProvider.fetch(pair);"}, "id": "CC-065", "lint_candidates": ["Allow comments containing tradeoff terms such as prefer, because, or during."], "lintability": "low", "problem": "Code has a clean-code risk related to explanation of intent: Explain why an unusual choice is intentional. Search terms that should match this issue include explanation of intent, explanation of, of intent, comment smell, stale comment.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Explanation Of Intent", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where explain why an unusual choice is intentional. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["clarification comments", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-066 Clarification Comments\nTopic: Comments\nAliases: clarification comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to clarification comments: Clarify awkward third-party behavior at the boundary, not throughout the codebase. Search terms that should match this issue include clarification comments, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where clarify awkward third-party behavior at the boundary, not throughout the codebase. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\n// The SDK returns cents as a string.\nconst amount = Money.fromCents(Number(response.amount));\nGood Python:\n# The SDK returns cents as a string.\namount = Money.from_cents(int(response.amount))\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Flag clarification comments far from third-party calls.\nLintability: high", "embedding_text": "Clean code pattern CC-066: Clarification Comments. Topic: Comments. Rule family: comments. Aliases and smell terms: clarification comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to clarification comments: Clarify awkward third-party behavior at the boundary, not throughout the codebase. Search terms that should match this issue include clarification comments, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where clarify awkward third-party behavior at the boundary, not throughout the codebase. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Flag clarification comments far from third-party calls.. Good TypeScript example: // The SDK returns cents as a string.\nconst amount = Money.fromCents(Number(response.amount)); Good Python example: # The SDK returns cents as a string.\namount = Money.from_cents(int(response.amount)) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "# The SDK returns cents as a string.\namount = Money.from_cents(int(response.amount))", "typescript": "// The SDK returns cents as a string.\nconst amount = Money.fromCents(Number(response.amount));"}, "id": "CC-066", "lint_candidates": ["Flag clarification comments far from third-party calls."], "lintability": "high", "problem": "Code has a clean-code risk related to clarification comments: Clarify awkward third-party behavior at the boundary, not throughout the codebase. Search terms that should match this issue include clarification comments, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Clarification Comments", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where clarify awkward third-party behavior at the boundary, not throughout the codebase. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["warning of consequences", "warning of", "of consequences", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-067 Warning Of Consequences\nTopic: Comments\nAliases: warning of consequences, warning of, of consequences, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to warning of consequences: Use warnings sparingly for traps that tests cannot make obvious. Search terms that should match this issue include warning of consequences, warning of, of consequences, comment smell, stale comment.\nUse when: Use this pattern when planning or reviewing code where use warnings sparingly for traps that tests cannot make obvious. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\n// Do not parallelize; the provider rejects concurrent captures for one invoice.\nfor (const capture of captures) await capturePayment(capture);\nGood Python:\n# Do not parallelize; the provider rejects concurrent captures for one invoice.\nfor capture in captures:\n    capture_payment(capture)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Allow warning comments near concurrency or provider constraints.\nLintability: medium", "embedding_text": "Clean code pattern CC-067: Warning Of Consequences. Topic: Comments. Rule family: comments. Aliases and smell terms: warning of consequences, warning of, of consequences, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to warning of consequences: Use warnings sparingly for traps that tests cannot make obvious. Search terms that should match this issue include warning of consequences, warning of, of consequences, comment smell, stale comment. Use when: Use this pattern when planning or reviewing code where use warnings sparingly for traps that tests cannot make obvious. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Allow warning comments near concurrency or provider constraints.. Good TypeScript example: // Do not parallelize; the provider rejects concurrent captures for one invoice.\nfor (const capture of captures) await capturePayment(capture); Good Python example: # Do not parallelize; the provider rejects concurrent captures for one invoice.\nfor capture in captures:\n    capture_payment(capture) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "# Do not parallelize; the provider rejects concurrent captures for one invoice.\nfor capture in captures:\n    capture_payment(capture)", "typescript": "// Do not parallelize; the provider rejects concurrent captures for one invoice.\nfor (const capture of captures) await capturePayment(capture);"}, "id": "CC-067", "lint_candidates": ["Allow warning comments near concurrency or provider constraints."], "lintability": "medium", "problem": "Code has a clean-code risk related to warning of consequences: Use warnings sparingly for traps that tests cannot make obvious. Search terms that should match this issue include warning of consequences, warning of, of consequences, comment smell, stale comment.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Warning Of Consequences", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where use warnings sparingly for traps that tests cannot make obvious. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["todo comments", "comment smell", "stale comment", "documentation noise", "comment guidance", "todo comment", "tracked work", "issue marker", "technical debt marker", "comments", "clean code", "code smell"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-068 TODO Comments\nTopic: Comments\nAliases: todo comments, comment smell, stale comment, documentation noise, comment guidance, todo comment, tracked work, issue marker, technical debt marker, comments, clean code, code smell\nProblem: Code has a clean-code risk related to todo comments: Make TODOs actionable, owned, and searchable. Search terms that should match this issue include todo comments, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where make TODOs actionable, owned, and searchable. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\n// TODO(BILL-412): remove legacy tax fallback after the July migration.\nconst tax = legacyTaxFallback(order);\nGood Python:\n# TODO(BILL-412): remove legacy tax fallback after the July migration.\ntax = legacy_tax_fallback(order)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Require issue IDs or owners in TODO comments.\nLintability: high", "embedding_text": "Clean code pattern CC-068: TODO Comments. Topic: Comments. Rule family: comments. Aliases and smell terms: todo comments, comment smell, stale comment, documentation noise, comment guidance, todo comment, tracked work, issue marker, technical debt marker, comments, clean code, code smell. Problem: Code has a clean-code risk related to todo comments: Make TODOs actionable, owned, and searchable. Search terms that should match this issue include todo comments, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where make TODOs actionable, owned, and searchable. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Require issue IDs or owners in TODO comments.. Good TypeScript example: // TODO(BILL-412): remove legacy tax fallback after the July migration.\nconst tax = legacyTaxFallback(order); Good Python example: # TODO(BILL-412): remove legacy tax fallback after the July migration.\ntax = legacy_tax_fallback(order) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "# TODO(BILL-412): remove legacy tax fallback after the July migration.\ntax = legacy_tax_fallback(order)", "typescript": "// TODO(BILL-412): remove legacy tax fallback after the July migration.\nconst tax = legacyTaxFallback(order);"}, "id": "CC-068", "lint_candidates": ["Require issue IDs or owners in TODO comments."], "lintability": "high", "problem": "Code has a clean-code risk related to todo comments: Make TODOs actionable, owned, and searchable. Search terms that should match this issue include todo comments, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "TODO Comments", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where make TODOs actionable, owned, and searchable. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["amplification comments", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-069 Amplification Comments\nTopic: Comments\nAliases: amplification comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to amplification comments: Highlight a small detail only when missing it causes real damage. Search terms that should match this issue include amplification comments, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where highlight a small detail only when missing it causes real damage. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\n// This comparison must stay case-sensitive; coupon codes are customer-visible.\nreturn inputCode === storedCode;\nGood Python:\n# This comparison must stay case-sensitive; coupon codes are customer-visible.\nreturn input_code == stored_code\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Allow comments that contain must/critical and a reason.\nLintability: low", "embedding_text": "Clean code pattern CC-069: Amplification Comments. Topic: Comments. Rule family: comments. Aliases and smell terms: amplification comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to amplification comments: Highlight a small detail only when missing it causes real damage. Search terms that should match this issue include amplification comments, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where highlight a small detail only when missing it causes real damage. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Allow comments that contain must/critical and a reason.. Good TypeScript example: // This comparison must stay case-sensitive; coupon codes are customer-visible.\nreturn inputCode === storedCode; Good Python example: # This comparison must stay case-sensitive; coupon codes are customer-visible.\nreturn input_code == stored_code Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "# This comparison must stay case-sensitive; coupon codes are customer-visible.\nreturn input_code == stored_code", "typescript": "// This comparison must stay case-sensitive; coupon codes are customer-visible.\nreturn inputCode === storedCode;"}, "id": "CC-069", "lint_candidates": ["Allow comments that contain must/critical and a reason."], "lintability": "low", "problem": "Code has a clean-code risk related to amplification comments: Highlight a small detail only when missing it causes real damage. Search terms that should match this issue include amplification comments, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Amplification Comments", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where highlight a small detail only when missing it causes real damage. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["javadocs in public apis", "javadocs in", "public apis", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-070 Javadocs In Public APIs\nTopic: Comments\nAliases: javadocs in public apis, javadocs in, public apis, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to javadocs in public apis: Document public APIs when callers cannot infer contract, units, or failure modes. Search terms that should match this issue include javadocs in public apis, javadocs in, public apis, comment smell, stale comment.\nUse when: Use this pattern when planning or reviewing code where document public APIs when callers cannot infer contract, units, or failure modes. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\n/** Captures a payment and throws PaymentDeclinedError when the provider rejects it. */\nexport function capturePayment(request: PaymentRequest): Promise<Receipt> {\n  return gateway.capture(request);\n}\nGood Python:\ndef capture_payment(request: PaymentRequest) -> Receipt:\n    \"\"\"Capture a payment or raise PaymentDeclinedError when rejected.\"\"\"\n    return gateway.capture(request)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Require docs on exported APIs in library packages only.\nLintability: low", "embedding_text": "Clean code pattern CC-070: Javadocs In Public APIs. Topic: Comments. Rule family: comments. Aliases and smell terms: javadocs in public apis, javadocs in, public apis, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to javadocs in public apis: Document public APIs when callers cannot infer contract, units, or failure modes. Search terms that should match this issue include javadocs in public apis, javadocs in, public apis, comment smell, stale comment. Use when: Use this pattern when planning or reviewing code where document public APIs when callers cannot infer contract, units, or failure modes. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Require docs on exported APIs in library packages only.. Good TypeScript example: /** Captures a payment and throws PaymentDeclinedError when the provider rejects it. */\nexport function capturePayment(request: PaymentRequest): Promise<Receipt> {\n  return gateway.capture(request);\n} Good Python example: def capture_payment(request: PaymentRequest) -> Receipt:\n    \"\"\"Capture a payment or raise PaymentDeclinedError when rejected.\"\"\"\n    return gateway.capture(request) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "def capture_payment(request: PaymentRequest) -> Receipt:\n    \"\"\"Capture a payment or raise PaymentDeclinedError when rejected.\"\"\"\n    return gateway.capture(request)", "typescript": "/** Captures a payment and throws PaymentDeclinedError when the provider rejects it. */\nexport function capturePayment(request: PaymentRequest): Promise<Receipt> {\n  return gateway.capture(request);\n}"}, "id": "CC-070", "lint_candidates": ["Require docs on exported APIs in library packages only."], "lintability": "low", "problem": "Code has a clean-code risk related to javadocs in public apis: Document public APIs when callers cannot infer contract, units, or failure modes. Search terms that should match this issue include javadocs in public apis, javadocs in, public apis, comment smell, stale comment.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Javadocs In Public APIs", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where document public APIs when callers cannot infer contract, units, or failure modes. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["bad comments", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-071 Bad Comments\nTopic: Comments\nAliases: bad comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to bad comments: Remove comments that duplicate, mislead, or compensate for unclear code. Search terms that should match this issue include bad comments, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where remove comments that duplicate, mislead, or compensate for unclear code. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nconst retryDelayMs = retryPolicy.delayFor(attempt);\nGood Python:\nretry_delay_ms = retry_policy.delay_for(attempt)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Flag comments that restate adjacent identifiers.\nLintability: high", "embedding_text": "Clean code pattern CC-071: Bad Comments. Topic: Comments. Rule family: comments. Aliases and smell terms: bad comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to bad comments: Remove comments that duplicate, mislead, or compensate for unclear code. Search terms that should match this issue include bad comments, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where remove comments that duplicate, mislead, or compensate for unclear code. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Flag comments that restate adjacent identifiers.. Good TypeScript example: const retryDelayMs = retryPolicy.delayFor(attempt); Good Python example: retry_delay_ms = retry_policy.delay_for(attempt) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "retry_delay_ms = retry_policy.delay_for(attempt)", "typescript": "const retryDelayMs = retryPolicy.delayFor(attempt);"}, "id": "CC-071", "lint_candidates": ["Flag comments that restate adjacent identifiers."], "lintability": "high", "problem": "Code has a clean-code risk related to bad comments: Remove comments that duplicate, mislead, or compensate for unclear code. Search terms that should match this issue include bad comments, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Bad Comments", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where remove comments that duplicate, mislead, or compensate for unclear code. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["mumbling comments", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-072 Mumbling Comments\nTopic: Comments\nAliases: mumbling comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to mumbling comments: Do not leave vague notes that force readers to guess their meaning. Search terms that should match this issue include mumbling comments, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where do not leave vague notes that force readers to guess their meaning. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nconst normalizedSku = normalizeSku(input.sku);\nGood Python:\nnormalized_sku = normalize_sku(payload['sku'])\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Flag comments containing unclear words such as hack, maybe, stuff, or magic without issue links.\nLintability: high", "embedding_text": "Clean code pattern CC-072: Mumbling Comments. Topic: Comments. Rule family: comments. Aliases and smell terms: mumbling comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to mumbling comments: Do not leave vague notes that force readers to guess their meaning. Search terms that should match this issue include mumbling comments, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where do not leave vague notes that force readers to guess their meaning. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Flag comments containing unclear words such as hack, maybe, stuff, or magic without issue links.. Good TypeScript example: const normalizedSku = normalizeSku(input.sku); Good Python example: normalized_sku = normalize_sku(payload['sku']) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "normalized_sku = normalize_sku(payload['sku'])", "typescript": "const normalizedSku = normalizeSku(input.sku);"}, "id": "CC-072", "lint_candidates": ["Flag comments containing unclear words such as hack, maybe, stuff, or magic without issue links."], "lintability": "high", "problem": "Code has a clean-code risk related to mumbling comments: Do not leave vague notes that force readers to guess their meaning. Search terms that should match this issue include mumbling comments, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Mumbling Comments", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where do not leave vague notes that force readers to guess their meaning. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["redundant comments", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-073 Redundant Comments\nTopic: Comments\nAliases: redundant comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to redundant comments: Delete comments that repeat exactly what the code says. Search terms that should match this issue include redundant comments, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where delete comments that repeat exactly what the code says. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nconst total = subtotal.plus(tax);\nGood Python:\ntotal = subtotal + tax\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Flag comments whose tokens overlap heavily with the following line.\nLintability: high", "embedding_text": "Clean code pattern CC-073: Redundant Comments. Topic: Comments. Rule family: comments. Aliases and smell terms: redundant comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to redundant comments: Delete comments that repeat exactly what the code says. Search terms that should match this issue include redundant comments, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where delete comments that repeat exactly what the code says. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Flag comments whose tokens overlap heavily with the following line.. Good TypeScript example: const total = subtotal.plus(tax); Good Python example: total = subtotal + tax Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "total = subtotal + tax", "typescript": "const total = subtotal.plus(tax);"}, "id": "CC-073", "lint_candidates": ["Flag comments whose tokens overlap heavily with the following line."], "lintability": "high", "problem": "Code has a clean-code risk related to redundant comments: Delete comments that repeat exactly what the code says. Search terms that should match this issue include redundant comments, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Redundant Comments", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where delete comments that repeat exactly what the code says. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["misleading comments", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-074 Misleading Comments\nTopic: Comments\nAliases: misleading comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to misleading comments: Prefer no comment over a stale or incorrect explanation. Search terms that should match this issue include misleading comments, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where prefer no comment over a stale or incorrect explanation. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nconst timeoutMs = settings.paymentTimeoutMs;\nGood Python:\ntimeout_ms = settings.payment_timeout_ms\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Flag comments mentioning values that differ from nearby literals or constants.\nLintability: high", "embedding_text": "Clean code pattern CC-074: Misleading Comments. Topic: Comments. Rule family: comments. Aliases and smell terms: misleading comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to misleading comments: Prefer no comment over a stale or incorrect explanation. Search terms that should match this issue include misleading comments, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where prefer no comment over a stale or incorrect explanation. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Flag comments mentioning values that differ from nearby literals or constants.. Good TypeScript example: const timeoutMs = settings.paymentTimeoutMs; Good Python example: timeout_ms = settings.payment_timeout_ms Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "timeout_ms = settings.payment_timeout_ms", "typescript": "const timeoutMs = settings.paymentTimeoutMs;"}, "id": "CC-074", "lint_candidates": ["Flag comments mentioning values that differ from nearby literals or constants."], "lintability": "high", "problem": "Code has a clean-code risk related to misleading comments: Prefer no comment over a stale or incorrect explanation. Search terms that should match this issue include misleading comments, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Misleading Comments", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where prefer no comment over a stale or incorrect explanation. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["mandated comments", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-075 Mandated Comments\nTopic: Comments\nAliases: mandated comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to mandated comments: Do not require boilerplate comments for every variable or private function. Search terms that should match this issue include mandated comments, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where do not require boilerplate comments for every variable or private function. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nfunction normalizeSku(sku: string): string {\n  return sku.trim().toUpperCase();\n}\nGood Python:\ndef normalize_sku(sku: str) -> str:\n    return sku.strip().upper()\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Disable rules requiring docs for every private member.\nLintability: low", "embedding_text": "Clean code pattern CC-075: Mandated Comments. Topic: Comments. Rule family: comments. Aliases and smell terms: mandated comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to mandated comments: Do not require boilerplate comments for every variable or private function. Search terms that should match this issue include mandated comments, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where do not require boilerplate comments for every variable or private function. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Disable rules requiring docs for every private member.. Good TypeScript example: function normalizeSku(sku: string): string {\n  return sku.trim().toUpperCase();\n} Good Python example: def normalize_sku(sku: str) -> str:\n    return sku.strip().upper() Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "def normalize_sku(sku: str) -> str:\n    return sku.strip().upper()", "typescript": "function normalizeSku(sku: string): string {\n  return sku.trim().toUpperCase();\n}"}, "id": "CC-075", "lint_candidates": ["Disable rules requiring docs for every private member."], "lintability": "low", "problem": "Code has a clean-code risk related to mandated comments: Do not require boilerplate comments for every variable or private function. Search terms that should match this issue include mandated comments, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Mandated Comments", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where do not require boilerplate comments for every variable or private function. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["journal comments", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-076 Journal Comments\nTopic: Comments\nAliases: journal comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to journal comments: Use version control for history instead of log-style comments in files. Search terms that should match this issue include journal comments, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where use version control for history instead of log-style comments in files. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nconst receipt = await paymentGateway.capture(request);\nGood Python:\nreceipt = payment_gateway.capture(request)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Flag dated change-log comments in source files.\nLintability: high", "embedding_text": "Clean code pattern CC-076: Journal Comments. Topic: Comments. Rule family: comments. Aliases and smell terms: journal comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to journal comments: Use version control for history instead of log-style comments in files. Search terms that should match this issue include journal comments, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where use version control for history instead of log-style comments in files. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Flag dated change-log comments in source files.. Good TypeScript example: const receipt = await paymentGateway.capture(request); Good Python example: receipt = payment_gateway.capture(request) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "receipt = payment_gateway.capture(request)", "typescript": "const receipt = await paymentGateway.capture(request);"}, "id": "CC-076", "lint_candidates": ["Flag dated change-log comments in source files."], "lintability": "high", "problem": "Code has a clean-code risk related to journal comments: Use version control for history instead of log-style comments in files. Search terms that should match this issue include journal comments, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Journal Comments", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where use version control for history instead of log-style comments in files. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["noise comments", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-077 Noise Comments\nTopic: Comments\nAliases: noise comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to noise comments: Remove filler comments that add no decision, warning, or contract. Search terms that should match this issue include noise comments, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where remove filler comments that add no decision, warning, or contract. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nreturn orderRepository.findById(orderId);\nGood Python:\nreturn order_repository.find_by_id(order_id)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Flag comments matching boilerplate patterns like default constructor.\nLintability: high", "embedding_text": "Clean code pattern CC-077: Noise Comments. Topic: Comments. Rule family: comments. Aliases and smell terms: noise comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to noise comments: Remove filler comments that add no decision, warning, or contract. Search terms that should match this issue include noise comments, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where remove filler comments that add no decision, warning, or contract. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Flag comments matching boilerplate patterns like default constructor.. Good TypeScript example: return orderRepository.findById(orderId); Good Python example: return order_repository.find_by_id(order_id) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "return order_repository.find_by_id(order_id)", "typescript": "return orderRepository.findById(orderId);"}, "id": "CC-077", "lint_candidates": ["Flag comments matching boilerplate patterns like default constructor."], "lintability": "high", "problem": "Code has a clean-code risk related to noise comments: Remove filler comments that add no decision, warning, or contract. Search terms that should match this issue include noise comments, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Noise Comments", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where remove filler comments that add no decision, warning, or contract. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["scary noise", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-078 Scary Noise\nTopic: Comments\nAliases: scary noise, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to scary noise: Avoid copied documentation blocks that hide the useful code. Search terms that should match this issue include scary noise, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where avoid copied documentation blocks that hide the useful code. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nexport class CustomerRepository {\n  findById(id: string): Promise<Customer | null> {\n    return db.customers.find(id);\n  }\n}\nGood Python:\nclass CustomerRepository:\n    def find_by_id(self, customer_id: str) -> Customer | None:\n        return db.customers.find(customer_id)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Flag repeated doc comments with only identifier substitutions.\nLintability: high", "embedding_text": "Clean code pattern CC-078: Scary Noise. Topic: Comments. Rule family: comments. Aliases and smell terms: scary noise, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to scary noise: Avoid copied documentation blocks that hide the useful code. Search terms that should match this issue include scary noise, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where avoid copied documentation blocks that hide the useful code. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Flag repeated doc comments with only identifier substitutions.. Good TypeScript example: export class CustomerRepository {\n  findById(id: string): Promise<Customer | null> {\n    return db.customers.find(id);\n  }\n} Good Python example: class CustomerRepository:\n    def find_by_id(self, customer_id: str) -> Customer | None:\n        return db.customers.find(customer_id) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "class CustomerRepository:\n    def find_by_id(self, customer_id: str) -> Customer | None:\n        return db.customers.find(customer_id)", "typescript": "export class CustomerRepository {\n  findById(id: string): Promise<Customer | null> {\n    return db.customers.find(id);\n  }\n}"}, "id": "CC-078", "lint_candidates": ["Flag repeated doc comments with only identifier substitutions."], "lintability": "high", "problem": "Code has a clean-code risk related to scary noise: Avoid copied documentation blocks that hide the useful code. Search terms that should match this issue include scary noise, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Scary Noise", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where avoid copied documentation blocks that hide the useful code. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["use a function or variable instead of a comment", "use a", "a comment", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-079 Use A Function Or Variable Instead Of A Comment\nTopic: Comments\nAliases: use a function or variable instead of a comment, use a, a comment, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to use a function or variable instead of a comment: Replace explanatory comments with named predicates when possible. Search terms that should match this issue include use a function or variable instead of a comment, use a, a comment, comment smell, stale comment.\nUse when: Use this pattern when planning or reviewing code where replace explanatory comments with named predicates when possible. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nconst isEligibleForRenewal = subscription.active && !subscription.cancelled;\nGood Python:\nis_eligible_for_renewal = subscription.active and not subscription.cancelled\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Suggest extracted variables for comments before conditions.\nLintability: low", "embedding_text": "Clean code pattern CC-079: Use A Function Or Variable Instead Of A Comment. Topic: Comments. Rule family: comments. Aliases and smell terms: use a function or variable instead of a comment, use a, a comment, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to use a function or variable instead of a comment: Replace explanatory comments with named predicates when possible. Search terms that should match this issue include use a function or variable instead of a comment, use a, a comment, comment smell, stale comment. Use when: Use this pattern when planning or reviewing code where replace explanatory comments with named predicates when possible. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Suggest extracted variables for comments before conditions.. Good TypeScript example: const isEligibleForRenewal = subscription.active && !subscription.cancelled; Good Python example: is_eligible_for_renewal = subscription.active and not subscription.cancelled Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "is_eligible_for_renewal = subscription.active and not subscription.cancelled", "typescript": "const isEligibleForRenewal = subscription.active && !subscription.cancelled;"}, "id": "CC-079", "lint_candidates": ["Suggest extracted variables for comments before conditions."], "lintability": "low", "problem": "Code has a clean-code risk related to use a function or variable instead of a comment: Replace explanatory comments with named predicates when possible. Search terms that should match this issue include use a function or variable instead of a comment, use a, a comment, comment smell, stale comment.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Use A Function Or Variable Instead Of A Comment", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where replace explanatory comments with named predicates when possible. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["position markers", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-080 Position Markers\nTopic: Comments\nAliases: position markers, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to position markers: Do not use banner comments to compensate for oversized files. Search terms that should match this issue include position markers, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where do not use banner comments to compensate for oversized files. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nexport function parseInvoice(input: unknown): Invoice {\n  return invoiceSchema.parse(input);\n}\nGood Python:\ndef parse_invoice(payload: object) -> Invoice:\n    return invoice_schema.parse(payload)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Flag repeated separator comments.\nLintability: high", "embedding_text": "Clean code pattern CC-080: Position Markers. Topic: Comments. Rule family: comments. Aliases and smell terms: position markers, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to position markers: Do not use banner comments to compensate for oversized files. Search terms that should match this issue include position markers, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where do not use banner comments to compensate for oversized files. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Flag repeated separator comments.. Good TypeScript example: export function parseInvoice(input: unknown): Invoice {\n  return invoiceSchema.parse(input);\n} Good Python example: def parse_invoice(payload: object) -> Invoice:\n    return invoice_schema.parse(payload) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "def parse_invoice(payload: object) -> Invoice:\n    return invoice_schema.parse(payload)", "typescript": "export function parseInvoice(input: unknown): Invoice {\n  return invoiceSchema.parse(input);\n}"}, "id": "CC-080", "lint_candidates": ["Flag repeated separator comments."], "lintability": "high", "problem": "Code has a clean-code risk related to position markers: Do not use banner comments to compensate for oversized files. Search terms that should match this issue include position markers, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Position Markers", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where do not use banner comments to compensate for oversized files. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["closing brace comments", "closing brace", "brace comments", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-081 Closing Brace Comments\nTopic: Comments\nAliases: closing brace comments, closing brace, brace comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to closing brace comments: Keep blocks short enough that closing comments are unnecessary. Search terms that should match this issue include closing brace comments, closing brace, brace comments, comment smell, stale comment.\nUse when: Use this pattern when planning or reviewing code where keep blocks short enough that closing comments are unnecessary. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nif (canArchive(order)) {\n  archive(order);\n}\nGood Python:\nif can_archive(order):\n    archive(order)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Flag comments after closing braces or dedents.\nLintability: high", "embedding_text": "Clean code pattern CC-081: Closing Brace Comments. Topic: Comments. Rule family: comments. Aliases and smell terms: closing brace comments, closing brace, brace comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to closing brace comments: Keep blocks short enough that closing comments are unnecessary. Search terms that should match this issue include closing brace comments, closing brace, brace comments, comment smell, stale comment. Use when: Use this pattern when planning or reviewing code where keep blocks short enough that closing comments are unnecessary. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Flag comments after closing braces or dedents.. Good TypeScript example: if (canArchive(order)) {\n  archive(order);\n} Good Python example: if can_archive(order):\n    archive(order) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "if can_archive(order):\n    archive(order)", "typescript": "if (canArchive(order)) {\n  archive(order);\n}"}, "id": "CC-081", "lint_candidates": ["Flag comments after closing braces or dedents."], "lintability": "high", "problem": "Code has a clean-code risk related to closing brace comments: Keep blocks short enough that closing comments are unnecessary. Search terms that should match this issue include closing brace comments, closing brace, brace comments, comment smell, stale comment.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Closing Brace Comments", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where keep blocks short enough that closing comments are unnecessary. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["attributions and bylines", "attributions and", "and bylines", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-082 Attributions And Bylines\nTopic: Comments\nAliases: attributions and bylines, attributions and, and bylines, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to attributions and bylines: Keep authorship in version control, not source comments. Search terms that should match this issue include attributions and bylines, attributions and, and bylines, comment smell, stale comment.\nUse when: Use this pattern when planning or reviewing code where keep authorship in version control, not source comments. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nexport function applyDiscount(cart: Cart, discount: Discount): Cart {\n  return cart.apply(discount);\n}\nGood Python:\ndef apply_discount(cart: Cart, discount: Discount) -> Cart:\n    return cart.apply(discount)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Flag author/by/date comments outside license headers.\nLintability: high", "embedding_text": "Clean code pattern CC-082: Attributions And Bylines. Topic: Comments. Rule family: comments. Aliases and smell terms: attributions and bylines, attributions and, and bylines, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to attributions and bylines: Keep authorship in version control, not source comments. Search terms that should match this issue include attributions and bylines, attributions and, and bylines, comment smell, stale comment. Use when: Use this pattern when planning or reviewing code where keep authorship in version control, not source comments. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Flag author/by/date comments outside license headers.. Good TypeScript example: export function applyDiscount(cart: Cart, discount: Discount): Cart {\n  return cart.apply(discount);\n} Good Python example: def apply_discount(cart: Cart, discount: Discount) -> Cart:\n    return cart.apply(discount) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "def apply_discount(cart: Cart, discount: Discount) -> Cart:\n    return cart.apply(discount)", "typescript": "export function applyDiscount(cart: Cart, discount: Discount): Cart {\n  return cart.apply(discount);\n}"}, "id": "CC-082", "lint_candidates": ["Flag author/by/date comments outside license headers."], "lintability": "high", "problem": "Code has a clean-code risk related to attributions and bylines: Keep authorship in version control, not source comments. Search terms that should match this issue include attributions and bylines, attributions and, and bylines, comment smell, stale comment.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Attributions And Bylines", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where keep authorship in version control, not source comments. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["commented-out code", "commented out code", "commented out", "out code", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# publish_receipt(receipt)\nsave_receipt(receipt)", "typescript": "// await publishReceipt(receipt);\nawait saveReceipt(receipt);"}, "display_text": "CC-083 Commented-Out Code\nTopic: Comments\nAliases: commented-out code, commented out code, commented out, out code, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to commented-out code: Remove dead code instead of leaving it commented beside live code. Search terms that should match this issue include commented-out code, commented out code, commented out, out code, comment smell.\nUse when: Use this pattern when planning or reviewing code where remove dead code instead of leaving it commented beside live code. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nconst receipt = await paymentGateway.capture(request);\nawait receiptRepository.save(receipt);\nGood Python:\nreceipt = payment_gateway.capture(request)\nreceipt_repository.save(receipt)\nBad TypeScript:\n// await publishReceipt(receipt);\nawait saveReceipt(receipt);\nBad Python:\n# publish_receipt(receipt)\nsave_receipt(receipt)\nLint candidates: Flag comment blocks containing code syntax.\nLintability: high", "embedding_text": "Clean code pattern CC-083: Commented-Out Code. Topic: Comments. Rule family: comments. Aliases and smell terms: commented-out code, commented out code, commented out, out code, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to commented-out code: Remove dead code instead of leaving it commented beside live code. Search terms that should match this issue include commented-out code, commented out code, commented out, out code, comment smell. Use when: Use this pattern when planning or reviewing code where remove dead code instead of leaving it commented beside live code. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Flag comment blocks containing code syntax.. Good TypeScript example: const receipt = await paymentGateway.capture(request);\nawait receiptRepository.save(receipt); Good Python example: receipt = payment_gateway.capture(request)\nreceipt_repository.save(receipt) Bad TypeScript example: // await publishReceipt(receipt);\nawait saveReceipt(receipt); Bad Python example: # publish_receipt(receipt)\nsave_receipt(receipt)", "good_examples": {"python": "receipt = payment_gateway.capture(request)\nreceipt_repository.save(receipt)", "typescript": "const receipt = await paymentGateway.capture(request);\nawait receiptRepository.save(receipt);"}, "id": "CC-083", "lint_candidates": ["Flag comment blocks containing code syntax."], "lintability": "high", "problem": "Code has a clean-code risk related to commented-out code: Remove dead code instead of leaving it commented beside live code. Search terms that should match this issue include commented-out code, commented out code, commented out, out code, comment smell.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Commented-Out Code", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where remove dead code instead of leaving it commented beside live code. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["html comments", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-084 HTML Comments\nTopic: Comments\nAliases: html comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to html comments: Avoid HTML markup in source comments unless generating external docs requires it. Search terms that should match this issue include html comments, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where avoid HTML markup in source comments unless generating external docs requires it. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\n/** Returns the account balance in the requested currency. */\nexport function balanceFor(account: Account, currency: string): Money {\n  return account.balance.convertTo(currency);\n}\nGood Python:\ndef balance_for(account: Account, currency: str) -> Money:\n    \"\"\"Return the account balance in the requested currency.\"\"\"\n    return account.balance.convert_to(currency)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Flag HTML tags in comments outside generated docs.\nLintability: high", "embedding_text": "Clean code pattern CC-084: HTML Comments. Topic: Comments. Rule family: comments. Aliases and smell terms: html comments, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to html comments: Avoid HTML markup in source comments unless generating external docs requires it. Search terms that should match this issue include html comments, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where avoid HTML markup in source comments unless generating external docs requires it. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Flag HTML tags in comments outside generated docs.. Good TypeScript example: /** Returns the account balance in the requested currency. */\nexport function balanceFor(account: Account, currency: string): Money {\n  return account.balance.convertTo(currency);\n} Good Python example: def balance_for(account: Account, currency: str) -> Money:\n    \"\"\"Return the account balance in the requested currency.\"\"\"\n    return account.balance.convert_to(currency) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "def balance_for(account: Account, currency: str) -> Money:\n    \"\"\"Return the account balance in the requested currency.\"\"\"\n    return account.balance.convert_to(currency)", "typescript": "/** Returns the account balance in the requested currency. */\nexport function balanceFor(account: Account, currency: string): Money {\n  return account.balance.convertTo(currency);\n}"}, "id": "CC-084", "lint_candidates": ["Flag HTML tags in comments outside generated docs."], "lintability": "high", "problem": "Code has a clean-code risk related to html comments: Avoid HTML markup in source comments unless generating external docs requires it. Search terms that should match this issue include html comments, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "HTML Comments", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where avoid HTML markup in source comments unless generating external docs requires it. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["nonlocal information", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-085 Nonlocal Information\nTopic: Comments\nAliases: nonlocal information, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to nonlocal information: Do not document distant systems in a local implementation comment. Search terms that should match this issue include nonlocal information, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where do not document distant systems in a local implementation comment. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nconst timeoutMs = config.paymentGateway.timeoutMs;\nawait paymentGateway.capture(request, { timeoutMs });\nGood Python:\ntimeout_seconds = config.payment_gateway.timeout_seconds\npayment_gateway.capture(request, timeout=timeout_seconds)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Flag comments naming services not referenced nearby.\nLintability: high", "embedding_text": "Clean code pattern CC-085: Nonlocal Information. Topic: Comments. Rule family: comments. Aliases and smell terms: nonlocal information, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to nonlocal information: Do not document distant systems in a local implementation comment. Search terms that should match this issue include nonlocal information, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where do not document distant systems in a local implementation comment. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Flag comments naming services not referenced nearby.. Good TypeScript example: const timeoutMs = config.paymentGateway.timeoutMs;\nawait paymentGateway.capture(request, { timeoutMs }); Good Python example: timeout_seconds = config.payment_gateway.timeout_seconds\npayment_gateway.capture(request, timeout=timeout_seconds) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "timeout_seconds = config.payment_gateway.timeout_seconds\npayment_gateway.capture(request, timeout=timeout_seconds)", "typescript": "const timeoutMs = config.paymentGateway.timeoutMs;\nawait paymentGateway.capture(request, { timeoutMs });"}, "id": "CC-085", "lint_candidates": ["Flag comments naming services not referenced nearby."], "lintability": "high", "problem": "Code has a clean-code risk related to nonlocal information: Do not document distant systems in a local implementation comment. Search terms that should match this issue include nonlocal information, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Nonlocal Information", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where do not document distant systems in a local implementation comment. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["too much information", "too much", "much information", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-086 Too Much Information\nTopic: Comments\nAliases: too much information, too much, much information, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to too much information: Keep comments focused on the local decision, not broad historical essays. Search terms that should match this issue include too much information, too much, much information, comment smell, stale comment.\nUse when: Use this pattern when planning or reviewing code where keep comments focused on the local decision, not broad historical essays. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\n// Preserve provider order because reconciliation compares row numbers.\nreturn rows;\nGood Python:\n# Preserve provider order because reconciliation compares row numbers.\nreturn rows\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Warn on long comments in function bodies.\nLintability: high", "embedding_text": "Clean code pattern CC-086: Too Much Information. Topic: Comments. Rule family: comments. Aliases and smell terms: too much information, too much, much information, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to too much information: Keep comments focused on the local decision, not broad historical essays. Search terms that should match this issue include too much information, too much, much information, comment smell, stale comment. Use when: Use this pattern when planning or reviewing code where keep comments focused on the local decision, not broad historical essays. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Warn on long comments in function bodies.. Good TypeScript example: // Preserve provider order because reconciliation compares row numbers.\nreturn rows; Good Python example: # Preserve provider order because reconciliation compares row numbers.\nreturn rows Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "# Preserve provider order because reconciliation compares row numbers.\nreturn rows", "typescript": "// Preserve provider order because reconciliation compares row numbers.\nreturn rows;"}, "id": "CC-086", "lint_candidates": ["Warn on long comments in function bodies."], "lintability": "high", "problem": "Code has a clean-code risk related to too much information: Keep comments focused on the local decision, not broad historical essays. Search terms that should match this issue include too much information, too much, much information, comment smell, stale comment.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Too Much Information", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where keep comments focused on the local decision, not broad historical essays. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["inobvious connection", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-087 Inobvious Connection\nTopic: Comments\nAliases: inobvious connection, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to inobvious connection: A comment and the code it explains should be directly connected. Search terms that should match this issue include inobvious connection, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where a comment and the code it explains should be directly connected. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nconst retryAfter = parseRetryAfter(response.headers);\nGood Python:\nretry_after = parse_retry_after(response.headers)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Flag comments separated from the referenced symbol by many lines.\nLintability: high", "embedding_text": "Clean code pattern CC-087: Inobvious Connection. Topic: Comments. Rule family: comments. Aliases and smell terms: inobvious connection, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to inobvious connection: A comment and the code it explains should be directly connected. Search terms that should match this issue include inobvious connection, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where a comment and the code it explains should be directly connected. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Flag comments separated from the referenced symbol by many lines.. Good TypeScript example: const retryAfter = parseRetryAfter(response.headers); Good Python example: retry_after = parse_retry_after(response.headers) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "retry_after = parse_retry_after(response.headers)", "typescript": "const retryAfter = parseRetryAfter(response.headers);"}, "id": "CC-087", "lint_candidates": ["Flag comments separated from the referenced symbol by many lines."], "lintability": "high", "problem": "Code has a clean-code risk related to inobvious connection: A comment and the code it explains should be directly connected. Search terms that should match this issue include inobvious connection, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Inobvious Connection", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where a comment and the code it explains should be directly connected. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["function headers", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-088 Function Headers\nTopic: Comments\nAliases: function headers, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to function headers: Prefer a well-named small function over a private function header comment. Search terms that should match this issue include function headers, comment smell, stale comment, documentation noise, comment guidance.\nUse when: Use this pattern when planning or reviewing code where prefer a well-named small function over a private function header comment. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nfunction calculateRefundAmount(order: Order): Money {\n  return order.paidAmount.minus(order.consumedValue);\n}\nGood Python:\ndef calculate_refund_amount(order: Order) -> Money:\n    return order.paid_amount - order.consumed_value\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Flag docblocks on short private functions when the name already says the same thing.\nLintability: high", "embedding_text": "Clean code pattern CC-088: Function Headers. Topic: Comments. Rule family: comments. Aliases and smell terms: function headers, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to function headers: Prefer a well-named small function over a private function header comment. Search terms that should match this issue include function headers, comment smell, stale comment, documentation noise, comment guidance. Use when: Use this pattern when planning or reviewing code where prefer a well-named small function over a private function header comment. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Flag docblocks on short private functions when the name already says the same thing.. Good TypeScript example: function calculateRefundAmount(order: Order): Money {\n  return order.paidAmount.minus(order.consumedValue);\n} Good Python example: def calculate_refund_amount(order: Order) -> Money:\n    return order.paid_amount - order.consumed_value Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "def calculate_refund_amount(order: Order) -> Money:\n    return order.paid_amount - order.consumed_value", "typescript": "function calculateRefundAmount(order: Order): Money {\n  return order.paidAmount.minus(order.consumedValue);\n}"}, "id": "CC-088", "lint_candidates": ["Flag docblocks on short private functions when the name already says the same thing."], "lintability": "high", "problem": "Code has a clean-code risk related to function headers: Prefer a well-named small function over a private function header comment. Search terms that should match this issue include function headers, comment smell, stale comment, documentation noise, comment guidance.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Function Headers", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where prefer a well-named small function over a private function header comment. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["javadocs in nonpublic code", "javadocs in", "nonpublic code", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-089 Javadocs In Nonpublic Code\nTopic: Comments\nAliases: javadocs in nonpublic code, javadocs in, nonpublic code, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to javadocs in nonpublic code: Avoid heavy API documentation for private implementation details. Search terms that should match this issue include javadocs in nonpublic code, javadocs in, nonpublic code, comment smell, stale comment.\nUse when: Use this pattern when planning or reviewing code where avoid heavy API documentation for private implementation details. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nfunction normalizeCountryCode(countryCode: string): string {\n  return countryCode.trim().toUpperCase();\n}\nGood Python:\ndef normalize_country_code(country_code: str) -> str:\n    return country_code.strip().upper()\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Warn on verbose docs for private helpers.\nLintability: medium", "embedding_text": "Clean code pattern CC-089: Javadocs In Nonpublic Code. Topic: Comments. Rule family: comments. Aliases and smell terms: javadocs in nonpublic code, javadocs in, nonpublic code, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to javadocs in nonpublic code: Avoid heavy API documentation for private implementation details. Search terms that should match this issue include javadocs in nonpublic code, javadocs in, nonpublic code, comment smell, stale comment. Use when: Use this pattern when planning or reviewing code where avoid heavy API documentation for private implementation details. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Warn on verbose docs for private helpers.. Good TypeScript example: function normalizeCountryCode(countryCode: string): string {\n  return countryCode.trim().toUpperCase();\n} Good Python example: def normalize_country_code(country_code: str) -> str:\n    return country_code.strip().upper() Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "def normalize_country_code(country_code: str) -> str:\n    return country_code.strip().upper()", "typescript": "function normalizeCountryCode(countryCode: string): string {\n  return countryCode.trim().toUpperCase();\n}"}, "id": "CC-089", "lint_candidates": ["Warn on verbose docs for private helpers."], "lintability": "medium", "problem": "Code has a clean-code risk related to javadocs in nonpublic code: Avoid heavy API documentation for private implementation details. Search terms that should match this issue include javadocs in nonpublic code, javadocs in, nonpublic code, comment smell, stale comment.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Javadocs In Nonpublic Code", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where avoid heavy API documentation for private implementation details. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["purpose of formatting", "purpose of", "of formatting", "formatting", "layout", "readability", "code style", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-090 Purpose Of Formatting\nTopic: Formatting\nAliases: purpose of formatting, purpose of, of formatting, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to purpose of formatting: Format code to communicate structure consistently. Search terms that should match this issue include purpose of formatting, purpose of, of formatting, formatting, layout.\nUse when: Use this pattern when planning or reviewing code where format code to communicate structure consistently. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst order = buildOrder(input);\nconst receipt = await submitOrder(order);\nGood Python:\norder = build_order(payload)\nreceipt = submit_order(order)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Enforce with formatter and style lint rules where possible.\nLintability: low", "embedding_text": "Clean code pattern CC-090: Purpose Of Formatting. Topic: Formatting. Rule family: formatting. Aliases and smell terms: purpose of formatting, purpose of, of formatting, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to purpose of formatting: Format code to communicate structure consistently. Search terms that should match this issue include purpose of formatting, purpose of, of formatting, formatting, layout. Use when: Use this pattern when planning or reviewing code where format code to communicate structure consistently. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Enforce with formatter and style lint rules where possible.. Good TypeScript example: const order = buildOrder(input);\nconst receipt = await submitOrder(order); Good Python example: order = build_order(payload)\nreceipt = submit_order(order) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "order = build_order(payload)\nreceipt = submit_order(order)", "typescript": "const order = buildOrder(input);\nconst receipt = await submitOrder(order);"}, "id": "CC-090", "lint_candidates": ["Enforce with formatter and style lint rules where possible."], "lintability": "low", "problem": "Code has a clean-code risk related to purpose of formatting: Format code to communicate structure consistently. Search terms that should match this issue include purpose of formatting, purpose of, of formatting, formatting, layout.", "rule_family": "formatting", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Purpose Of Formatting", "topic": "Formatting", "use_when": "Use this pattern when planning or reviewing code where format code to communicate structure consistently. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["vertical formatting", "formatting", "layout", "readability", "code style", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-091 Vertical Formatting\nTopic: Formatting\nAliases: vertical formatting, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to vertical formatting: Use vertical structure to reveal the story of a file. Search terms that should match this issue include vertical formatting, formatting, layout, readability, code style.\nUse when: Use this pattern when planning or reviewing code where use vertical structure to reveal the story of a file. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst quote = priceOrder(order);\n\nawait quoteRepository.save(quote);\nGood Python:\nquote = price_order(order)\n\nquote_repository.save(quote)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Enforce with formatter and style lint rules where possible.\nLintability: low", "embedding_text": "Clean code pattern CC-091: Vertical Formatting. Topic: Formatting. Rule family: formatting. Aliases and smell terms: vertical formatting, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to vertical formatting: Use vertical structure to reveal the story of a file. Search terms that should match this issue include vertical formatting, formatting, layout, readability, code style. Use when: Use this pattern when planning or reviewing code where use vertical structure to reveal the story of a file. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Enforce with formatter and style lint rules where possible.. Good TypeScript example: const quote = priceOrder(order);\n\nawait quoteRepository.save(quote); Good Python example: quote = price_order(order)\n\nquote_repository.save(quote) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "quote = price_order(order)\n\nquote_repository.save(quote)", "typescript": "const quote = priceOrder(order);\n\nawait quoteRepository.save(quote);"}, "id": "CC-091", "lint_candidates": ["Enforce with formatter and style lint rules where possible."], "lintability": "low", "problem": "Code has a clean-code risk related to vertical formatting: Use vertical structure to reveal the story of a file. Search terms that should match this issue include vertical formatting, formatting, layout, readability, code style.", "rule_family": "formatting", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Vertical Formatting", "topic": "Formatting", "use_when": "Use this pattern when planning or reviewing code where use vertical structure to reveal the story of a file. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["newspaper metaphor", "formatting", "layout", "readability", "code style", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-092 Newspaper Metaphor\nTopic: Formatting\nAliases: newspaper metaphor, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to newspaper metaphor: Put high-level concepts first, then lower-level details. Search terms that should match this issue include newspaper metaphor, formatting, layout, readability, code style.\nUse when: Use this pattern when planning or reviewing code where put high-level concepts first, then lower-level details. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nexport async function checkout(cart: Cart): Promise<Receipt> {\n  return submitPricedOrder(priceCart(cart));\n}\nGood Python:\ndef checkout(cart: Cart) -> Receipt:\n    return submit_priced_order(price_cart(cart))\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Enforce with formatter and style lint rules where possible.\nLintability: low", "embedding_text": "Clean code pattern CC-092: Newspaper Metaphor. Topic: Formatting. Rule family: formatting. Aliases and smell terms: newspaper metaphor, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to newspaper metaphor: Put high-level concepts first, then lower-level details. Search terms that should match this issue include newspaper metaphor, formatting, layout, readability, code style. Use when: Use this pattern when planning or reviewing code where put high-level concepts first, then lower-level details. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Enforce with formatter and style lint rules where possible.. Good TypeScript example: export async function checkout(cart: Cart): Promise<Receipt> {\n  return submitPricedOrder(priceCart(cart));\n} Good Python example: def checkout(cart: Cart) -> Receipt:\n    return submit_priced_order(price_cart(cart)) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def checkout(cart: Cart) -> Receipt:\n    return submit_priced_order(price_cart(cart))", "typescript": "export async function checkout(cart: Cart): Promise<Receipt> {\n  return submitPricedOrder(priceCart(cart));\n}"}, "id": "CC-092", "lint_candidates": ["Enforce with formatter and style lint rules where possible."], "lintability": "low", "problem": "Code has a clean-code risk related to newspaper metaphor: Put high-level concepts first, then lower-level details. Search terms that should match this issue include newspaper metaphor, formatting, layout, readability, code style.", "rule_family": "formatting", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Newspaper Metaphor", "topic": "Formatting", "use_when": "Use this pattern when planning or reviewing code where put high-level concepts first, then lower-level details. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["vertical openness between concepts", "vertical openness", "between concepts", "formatting", "layout", "readability", "code style", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-093 Vertical Openness Between Concepts\nTopic: Formatting\nAliases: vertical openness between concepts, vertical openness, between concepts, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to vertical openness between concepts: Separate distinct ideas with blank lines. Search terms that should match this issue include vertical openness between concepts, vertical openness, between concepts, formatting, layout.\nUse when: Use this pattern when planning or reviewing code where separate distinct ideas with blank lines. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst order = buildOrder(input);\nconst quote = priceOrder(order);\n\nawait publishQuoteCreated(quote);\nGood Python:\norder = build_order(payload)\nquote = price_order(order)\n\npublish_quote_created(quote)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Enforce with formatter and style lint rules where possible.\nLintability: low", "embedding_text": "Clean code pattern CC-093: Vertical Openness Between Concepts. Topic: Formatting. Rule family: formatting. Aliases and smell terms: vertical openness between concepts, vertical openness, between concepts, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to vertical openness between concepts: Separate distinct ideas with blank lines. Search terms that should match this issue include vertical openness between concepts, vertical openness, between concepts, formatting, layout. Use when: Use this pattern when planning or reviewing code where separate distinct ideas with blank lines. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Enforce with formatter and style lint rules where possible.. Good TypeScript example: const order = buildOrder(input);\nconst quote = priceOrder(order);\n\nawait publishQuoteCreated(quote); Good Python example: order = build_order(payload)\nquote = price_order(order)\n\npublish_quote_created(quote) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "order = build_order(payload)\nquote = price_order(order)\n\npublish_quote_created(quote)", "typescript": "const order = buildOrder(input);\nconst quote = priceOrder(order);\n\nawait publishQuoteCreated(quote);"}, "id": "CC-093", "lint_candidates": ["Enforce with formatter and style lint rules where possible."], "lintability": "low", "problem": "Code has a clean-code risk related to vertical openness between concepts: Separate distinct ideas with blank lines. Search terms that should match this issue include vertical openness between concepts, vertical openness, between concepts, formatting, layout.", "rule_family": "formatting", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Vertical Openness Between Concepts", "topic": "Formatting", "use_when": "Use this pattern when planning or reviewing code where separate distinct ideas with blank lines. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["vertical density", "formatting", "layout", "readability", "code style", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-094 Vertical Density\nTopic: Formatting\nAliases: vertical density, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to vertical density: Keep tightly related lines adjacent. Search terms that should match this issue include vertical density, formatting, layout, readability, code style.\nUse when: Use this pattern when planning or reviewing code where keep tightly related lines adjacent. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst amount = parseAmount(input.amount);\nconst currency = parseCurrency(input.currency);\nconst money = new Money(amount, currency);\nGood Python:\namount = parse_amount(payload['amount'])\ncurrency = parse_currency(payload['currency'])\nmoney = Money(amount, currency)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Enforce with formatter and style lint rules where possible.\nLintability: low", "embedding_text": "Clean code pattern CC-094: Vertical Density. Topic: Formatting. Rule family: formatting. Aliases and smell terms: vertical density, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to vertical density: Keep tightly related lines adjacent. Search terms that should match this issue include vertical density, formatting, layout, readability, code style. Use when: Use this pattern when planning or reviewing code where keep tightly related lines adjacent. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Enforce with formatter and style lint rules where possible.. Good TypeScript example: const amount = parseAmount(input.amount);\nconst currency = parseCurrency(input.currency);\nconst money = new Money(amount, currency); Good Python example: amount = parse_amount(payload['amount'])\ncurrency = parse_currency(payload['currency'])\nmoney = Money(amount, currency) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "amount = parse_amount(payload['amount'])\ncurrency = parse_currency(payload['currency'])\nmoney = Money(amount, currency)", "typescript": "const amount = parseAmount(input.amount);\nconst currency = parseCurrency(input.currency);\nconst money = new Money(amount, currency);"}, "id": "CC-094", "lint_candidates": ["Enforce with formatter and style lint rules where possible."], "lintability": "low", "problem": "Code has a clean-code risk related to vertical density: Keep tightly related lines adjacent. Search terms that should match this issue include vertical density, formatting, layout, readability, code style.", "rule_family": "formatting", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Vertical Density", "topic": "Formatting", "use_when": "Use this pattern when planning or reviewing code where keep tightly related lines adjacent. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["vertical distance", "formatting", "layout", "readability", "code style", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-095 Vertical Distance\nTopic: Formatting\nAliases: vertical distance, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to vertical distance: Keep declarations and helpers near the code that uses them. Search terms that should match this issue include vertical distance, formatting, layout, readability, code style.\nUse when: Use this pattern when planning or reviewing code where keep declarations and helpers near the code that uses them. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst RETRYABLE_CODES = new Set(['timeout']);\nfunction shouldRetry(error: ProviderError): boolean {\n  return RETRYABLE_CODES.has(error.code);\n}\nGood Python:\nRETRYABLE_CODES = {'timeout'}\n\ndef should_retry(error: ProviderError) -> bool:\n    return error.code in RETRYABLE_CODES\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Enforce with formatter and style lint rules where possible.\nLintability: low", "embedding_text": "Clean code pattern CC-095: Vertical Distance. Topic: Formatting. Rule family: formatting. Aliases and smell terms: vertical distance, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to vertical distance: Keep declarations and helpers near the code that uses them. Search terms that should match this issue include vertical distance, formatting, layout, readability, code style. Use when: Use this pattern when planning or reviewing code where keep declarations and helpers near the code that uses them. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Enforce with formatter and style lint rules where possible.. Good TypeScript example: const RETRYABLE_CODES = new Set(['timeout']);\nfunction shouldRetry(error: ProviderError): boolean {\n  return RETRYABLE_CODES.has(error.code);\n} Good Python example: RETRYABLE_CODES = {'timeout'}\n\ndef should_retry(error: ProviderError) -> bool:\n    return error.code in RETRYABLE_CODES Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "RETRYABLE_CODES = {'timeout'}\n\ndef should_retry(error: ProviderError) -> bool:\n    return error.code in RETRYABLE_CODES", "typescript": "const RETRYABLE_CODES = new Set(['timeout']);\nfunction shouldRetry(error: ProviderError): boolean {\n  return RETRYABLE_CODES.has(error.code);\n}"}, "id": "CC-095", "lint_candidates": ["Enforce with formatter and style lint rules where possible."], "lintability": "low", "problem": "Code has a clean-code risk related to vertical distance: Keep declarations and helpers near the code that uses them. Search terms that should match this issue include vertical distance, formatting, layout, readability, code style.", "rule_family": "formatting", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Vertical Distance", "topic": "Formatting", "use_when": "Use this pattern when planning or reviewing code where keep declarations and helpers near the code that uses them. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["vertical ordering", "formatting", "layout", "readability", "code style", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-096 Vertical Ordering\nTopic: Formatting\nAliases: vertical ordering, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to vertical ordering: Order code from public/high-level behavior to private details. Search terms that should match this issue include vertical ordering, formatting, layout, readability, code style.\nUse when: Use this pattern when planning or reviewing code where order code from public/high-level behavior to private details. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nexport function createReceipt(order: Order): Receipt {\n  return buildReceipt(order);\n}\n\nfunction buildReceipt(order: Order): Receipt {\n  return Receipt.from(order);\n}\nGood Python:\ndef create_receipt(order: Order) -> Receipt:\n    return build_receipt(order)\n\ndef build_receipt(order: Order) -> Receipt:\n    return Receipt.from_order(order)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Enforce with formatter and style lint rules where possible.\nLintability: low", "embedding_text": "Clean code pattern CC-096: Vertical Ordering. Topic: Formatting. Rule family: formatting. Aliases and smell terms: vertical ordering, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to vertical ordering: Order code from public/high-level behavior to private details. Search terms that should match this issue include vertical ordering, formatting, layout, readability, code style. Use when: Use this pattern when planning or reviewing code where order code from public/high-level behavior to private details. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Enforce with formatter and style lint rules where possible.. Good TypeScript example: export function createReceipt(order: Order): Receipt {\n  return buildReceipt(order);\n}\n\nfunction buildReceipt(order: Order): Receipt {\n  return Receipt.from(order);\n} Good Python example: def create_receipt(order: Order) -> Receipt:\n    return build_receipt(order)\n\ndef build_receipt(order: Order) -> Receipt:\n    return Receipt.from_order(order) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def create_receipt(order: Order) -> Receipt:\n    return build_receipt(order)\n\ndef build_receipt(order: Order) -> Receipt:\n    return Receipt.from_order(order)", "typescript": "export function createReceipt(order: Order): Receipt {\n  return buildReceipt(order);\n}\n\nfunction buildReceipt(order: Order): Receipt {\n  return Receipt.from(order);\n}"}, "id": "CC-096", "lint_candidates": ["Enforce with formatter and style lint rules where possible."], "lintability": "low", "problem": "Code has a clean-code risk related to vertical ordering: Order code from public/high-level behavior to private details. Search terms that should match this issue include vertical ordering, formatting, layout, readability, code style.", "rule_family": "formatting", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Vertical Ordering", "topic": "Formatting", "use_when": "Use this pattern when planning or reviewing code where order code from public/high-level behavior to private details. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["horizontal formatting", "formatting", "layout", "readability", "code style", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-097 Horizontal Formatting\nTopic: Formatting\nAliases: horizontal formatting, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to horizontal formatting: Keep lines short and expressions readable. Search terms that should match this issue include horizontal formatting, formatting, layout, readability, code style.\nUse when: Use this pattern when planning or reviewing code where keep lines short and expressions readable. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst total = subtotal.plus(tax).minus(discount);\nGood Python:\ntotal = subtotal + tax - discount\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Enforce with formatter and style lint rules where possible.\nLintability: low", "embedding_text": "Clean code pattern CC-097: Horizontal Formatting. Topic: Formatting. Rule family: formatting. Aliases and smell terms: horizontal formatting, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to horizontal formatting: Keep lines short and expressions readable. Search terms that should match this issue include horizontal formatting, formatting, layout, readability, code style. Use when: Use this pattern when planning or reviewing code where keep lines short and expressions readable. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Enforce with formatter and style lint rules where possible.. Good TypeScript example: const total = subtotal.plus(tax).minus(discount); Good Python example: total = subtotal + tax - discount Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "total = subtotal + tax - discount", "typescript": "const total = subtotal.plus(tax).minus(discount);"}, "id": "CC-097", "lint_candidates": ["Enforce with formatter and style lint rules where possible."], "lintability": "low", "problem": "Code has a clean-code risk related to horizontal formatting: Keep lines short and expressions readable. Search terms that should match this issue include horizontal formatting, formatting, layout, readability, code style.", "rule_family": "formatting", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Horizontal Formatting", "topic": "Formatting", "use_when": "Use this pattern when planning or reviewing code where keep lines short and expressions readable. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["horizontal openness and density", "horizontal openness", "and density", "formatting", "layout", "readability", "code style", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-098 Horizontal Openness And Density\nTopic: Formatting\nAliases: horizontal openness and density, horizontal openness, and density, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to horizontal openness and density: Use spaces to separate operators and arguments in conventional ways. Search terms that should match this issue include horizontal openness and density, horizontal openness, and density, formatting, layout.\nUse when: Use this pattern when planning or reviewing code where use spaces to separate operators and arguments in conventional ways. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst fee = amount.multiply(rate).plus(minimumFee);\nGood Python:\nfee = amount * rate + minimum_fee\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Enforce with formatter and style lint rules where possible.\nLintability: low", "embedding_text": "Clean code pattern CC-098: Horizontal Openness And Density. Topic: Formatting. Rule family: formatting. Aliases and smell terms: horizontal openness and density, horizontal openness, and density, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to horizontal openness and density: Use spaces to separate operators and arguments in conventional ways. Search terms that should match this issue include horizontal openness and density, horizontal openness, and density, formatting, layout. Use when: Use this pattern when planning or reviewing code where use spaces to separate operators and arguments in conventional ways. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Enforce with formatter and style lint rules where possible.. Good TypeScript example: const fee = amount.multiply(rate).plus(minimumFee); Good Python example: fee = amount * rate + minimum_fee Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "fee = amount * rate + minimum_fee", "typescript": "const fee = amount.multiply(rate).plus(minimumFee);"}, "id": "CC-098", "lint_candidates": ["Enforce with formatter and style lint rules where possible."], "lintability": "low", "problem": "Code has a clean-code risk related to horizontal openness and density: Use spaces to separate operators and arguments in conventional ways. Search terms that should match this issue include horizontal openness and density, horizontal openness, and density, formatting, layout.", "rule_family": "formatting", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Horizontal Openness And Density", "topic": "Formatting", "use_when": "Use this pattern when planning or reviewing code where use spaces to separate operators and arguments in conventional ways. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["horizontal alignment", "formatting", "layout", "readability", "code style", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-099 Horizontal Alignment\nTopic: Formatting\nAliases: horizontal alignment, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to horizontal alignment: Avoid alignment that emphasizes columns over relationships. Search terms that should match this issue include horizontal alignment, formatting, layout, readability, code style.\nUse when: Use this pattern when planning or reviewing code where avoid alignment that emphasizes columns over relationships. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst id = customer.id;\nconst email = customer.email;\nGood Python:\ncustomer_id = customer.id\nemail = customer.email\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Enforce with formatter and style lint rules where possible.\nLintability: low", "embedding_text": "Clean code pattern CC-099: Horizontal Alignment. Topic: Formatting. Rule family: formatting. Aliases and smell terms: horizontal alignment, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to horizontal alignment: Avoid alignment that emphasizes columns over relationships. Search terms that should match this issue include horizontal alignment, formatting, layout, readability, code style. Use when: Use this pattern when planning or reviewing code where avoid alignment that emphasizes columns over relationships. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Enforce with formatter and style lint rules where possible.. Good TypeScript example: const id = customer.id;\nconst email = customer.email; Good Python example: customer_id = customer.id\nemail = customer.email Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "customer_id = customer.id\nemail = customer.email", "typescript": "const id = customer.id;\nconst email = customer.email;"}, "id": "CC-099", "lint_candidates": ["Enforce with formatter and style lint rules where possible."], "lintability": "low", "problem": "Code has a clean-code risk related to horizontal alignment: Avoid alignment that emphasizes columns over relationships. Search terms that should match this issue include horizontal alignment, formatting, layout, readability, code style.", "rule_family": "formatting", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Horizontal Alignment", "topic": "Formatting", "use_when": "Use this pattern when planning or reviewing code where avoid alignment that emphasizes columns over relationships. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["indentation", "formatting", "layout", "readability", "code style", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-100 Indentation\nTopic: Formatting\nAliases: indentation, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to indentation: Indent blocks so nesting and ownership are obvious. Search terms that should match this issue include indentation, formatting, layout, readability, code style.\nUse when: Use this pattern when planning or reviewing code where indent blocks so nesting and ownership are obvious. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nif (isValid(order)) {\n  submit(order);\n}\nGood Python:\nif is_valid(order):\n    submit(order)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Enforce with formatter and style lint rules where possible.\nLintability: low", "embedding_text": "Clean code pattern CC-100: Indentation. Topic: Formatting. Rule family: formatting. Aliases and smell terms: indentation, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to indentation: Indent blocks so nesting and ownership are obvious. Search terms that should match this issue include indentation, formatting, layout, readability, code style. Use when: Use this pattern when planning or reviewing code where indent blocks so nesting and ownership are obvious. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Enforce with formatter and style lint rules where possible.. Good TypeScript example: if (isValid(order)) {\n  submit(order);\n} Good Python example: if is_valid(order):\n    submit(order) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "if is_valid(order):\n    submit(order)", "typescript": "if (isValid(order)) {\n  submit(order);\n}"}, "id": "CC-100", "lint_candidates": ["Enforce with formatter and style lint rules where possible."], "lintability": "low", "problem": "Code has a clean-code risk related to indentation: Indent blocks so nesting and ownership are obvious. Search terms that should match this issue include indentation, formatting, layout, readability, code style.", "rule_family": "formatting", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Indentation", "topic": "Formatting", "use_when": "Use this pattern when planning or reviewing code where indent blocks so nesting and ownership are obvious. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["dummy scopes", "formatting", "layout", "readability", "code style", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-101 Dummy Scopes\nTopic: Formatting\nAliases: dummy scopes, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to dummy scopes: Avoid empty or dummy scopes that obscure control flow. Search terms that should match this issue include dummy scopes, formatting, layout, readability, code style.\nUse when: Use this pattern when planning or reviewing code where avoid empty or dummy scopes that obscure control flow. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nwhile (queue.hasNext()) {\n  process(queue.next());\n}\nGood Python:\nwhile queue.has_next():\n    process(queue.next())\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Enforce with formatter and style lint rules where possible.\nLintability: low", "embedding_text": "Clean code pattern CC-101: Dummy Scopes. Topic: Formatting. Rule family: formatting. Aliases and smell terms: dummy scopes, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to dummy scopes: Avoid empty or dummy scopes that obscure control flow. Search terms that should match this issue include dummy scopes, formatting, layout, readability, code style. Use when: Use this pattern when planning or reviewing code where avoid empty or dummy scopes that obscure control flow. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Enforce with formatter and style lint rules where possible.. Good TypeScript example: while (queue.hasNext()) {\n  process(queue.next());\n} Good Python example: while queue.has_next():\n    process(queue.next()) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "while queue.has_next():\n    process(queue.next())", "typescript": "while (queue.hasNext()) {\n  process(queue.next());\n}"}, "id": "CC-101", "lint_candidates": ["Enforce with formatter and style lint rules where possible."], "lintability": "low", "problem": "Code has a clean-code risk related to dummy scopes: Avoid empty or dummy scopes that obscure control flow. Search terms that should match this issue include dummy scopes, formatting, layout, readability, code style.", "rule_family": "formatting", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Dummy Scopes", "topic": "Formatting", "use_when": "Use this pattern when planning or reviewing code where avoid empty or dummy scopes that obscure control flow. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["team rules", "formatting", "layout", "readability", "code style", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-102 Team Rules\nTopic: Formatting\nAliases: team rules, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to team rules: Follow shared formatter and style rules instead of personal preference. Search terms that should match this issue include team rules, formatting, layout, readability, code style.\nUse when: Use this pattern when planning or reviewing code where follow shared formatter and style rules instead of personal preference. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nexport const formatterConfig = { printWidth: 100 };\nGood Python:\nLINE_LENGTH = 100\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Enforce with formatter and style lint rules where possible.\nLintability: low", "embedding_text": "Clean code pattern CC-102: Team Rules. Topic: Formatting. Rule family: formatting. Aliases and smell terms: team rules, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to team rules: Follow shared formatter and style rules instead of personal preference. Search terms that should match this issue include team rules, formatting, layout, readability, code style. Use when: Use this pattern when planning or reviewing code where follow shared formatter and style rules instead of personal preference. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Enforce with formatter and style lint rules where possible.. Good TypeScript example: export const formatterConfig = { printWidth: 100 }; Good Python example: LINE_LENGTH = 100 Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "LINE_LENGTH = 100", "typescript": "export const formatterConfig = { printWidth: 100 };"}, "id": "CC-102", "lint_candidates": ["Enforce with formatter and style lint rules where possible."], "lintability": "low", "problem": "Code has a clean-code risk related to team rules: Follow shared formatter and style rules instead of personal preference. Search terms that should match this issue include team rules, formatting, layout, readability, code style.", "rule_family": "formatting", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Team Rules", "topic": "Formatting", "use_when": "Use this pattern when planning or reviewing code where follow shared formatter and style rules instead of personal preference. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["formatting rules", "formatting", "layout", "readability", "code style", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-103 Formatting Rules\nTopic: Formatting\nAliases: formatting rules, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to formatting rules: Let automated formatting handle mechanical layout decisions. Search terms that should match this issue include formatting rules, formatting, layout, readability, code style.\nUse when: Use this pattern when planning or reviewing code where let automated formatting handle mechanical layout decisions. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst formatted = formatter.format(sourceText);\nGood Python:\nformatted = formatter.format(source_text)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Enforce with formatter and style lint rules where possible.\nLintability: low", "embedding_text": "Clean code pattern CC-103: Formatting Rules. Topic: Formatting. Rule family: formatting. Aliases and smell terms: formatting rules, formatting, layout, readability, code style, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to formatting rules: Let automated formatting handle mechanical layout decisions. Search terms that should match this issue include formatting rules, formatting, layout, readability, code style. Use when: Use this pattern when planning or reviewing code where let automated formatting handle mechanical layout decisions. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Enforce with formatter and style lint rules where possible.. Good TypeScript example: const formatted = formatter.format(sourceText); Good Python example: formatted = formatter.format(source_text) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "formatted = formatter.format(source_text)", "typescript": "const formatted = formatter.format(sourceText);"}, "id": "CC-103", "lint_candidates": ["Enforce with formatter and style lint rules where possible."], "lintability": "low", "problem": "Code has a clean-code risk related to formatting rules: Let automated formatting handle mechanical layout decisions. Search terms that should match this issue include formatting rules, formatting, layout, readability, code style.", "rule_family": "formatting", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Formatting Rules", "topic": "Formatting", "use_when": "Use this pattern when planning or reviewing code where let automated formatting handle mechanical layout decisions. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["data abstraction", "data structure", "object design", "encapsulation", "objects and data structures", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-104 Data Abstraction\nTopic: Objects and Data Structures\nAliases: data abstraction, data structure, object design, encapsulation, objects and data structures, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to data abstraction: Expose operations that preserve invariants instead of raw representation. Search terms that should match this issue include data abstraction, data structure, object design, encapsulation, objects and data structures.\nUse when: Use this pattern when planning or reviewing code where expose operations that preserve invariants instead of raw representation. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nwallet.canCover(amount)\nGood Python:\nwallet.can_cover(amount)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-104: Data Abstraction. Topic: Objects and Data Structures. Rule family: objects_data. Aliases and smell terms: data abstraction, data structure, object design, encapsulation, objects and data structures, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to data abstraction: Expose operations that preserve invariants instead of raw representation. Search terms that should match this issue include data abstraction, data structure, object design, encapsulation, objects and data structures. Use when: Use this pattern when planning or reviewing code where expose operations that preserve invariants instead of raw representation. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: wallet.canCover(amount) Good Python example: wallet.can_cover(amount) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "wallet.can_cover(amount)", "typescript": "wallet.canCover(amount)"}, "id": "CC-104", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to data abstraction: Expose operations that preserve invariants instead of raw representation. Search terms that should match this issue include data abstraction, data structure, object design, encapsulation, objects and data structures.", "rule_family": "objects_data", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Data Abstraction", "topic": "Objects and Data Structures", "use_when": "Use this pattern when planning or reviewing code where expose operations that preserve invariants instead of raw representation. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["data object anti-symmetry", "data object anti symmetry", "data object", "anti symmetry", "data structure", "object design", "encapsulation", "data abstraction", "objects and data structures", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-105 Data Object Anti-Symmetry\nTopic: Objects and Data Structures\nAliases: data object anti-symmetry, data object anti symmetry, data object, anti symmetry, data structure, object design, encapsulation, data abstraction, objects and data structures, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to data object anti-symmetry: Choose objects for behavior and data structures for transparent data transfer. Search terms that should match this issue include data object anti-symmetry, data object anti symmetry, data object, anti symmetry, data structure.\nUse when: Use this pattern when planning or reviewing code where choose objects for behavior and data structures for transparent data transfer. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst total = order.total();\nGood Python:\ntotal = order.total()\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-105: Data Object Anti-Symmetry. Topic: Objects and Data Structures. Rule family: objects_data. Aliases and smell terms: data object anti-symmetry, data object anti symmetry, data object, anti symmetry, data structure, object design, encapsulation, data abstraction, objects and data structures, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to data object anti-symmetry: Choose objects for behavior and data structures for transparent data transfer. Search terms that should match this issue include data object anti-symmetry, data object anti symmetry, data object, anti symmetry, data structure. Use when: Use this pattern when planning or reviewing code where choose objects for behavior and data structures for transparent data transfer. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const total = order.total(); Good Python example: total = order.total() Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "total = order.total()", "typescript": "const total = order.total();"}, "id": "CC-105", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to data object anti-symmetry: Choose objects for behavior and data structures for transparent data transfer. Search terms that should match this issue include data object anti-symmetry, data object anti symmetry, data object, anti symmetry, data structure.", "rule_family": "objects_data", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Data Object Anti-Symmetry", "topic": "Objects and Data Structures", "use_when": "Use this pattern when planning or reviewing code where choose objects for behavior and data structures for transparent data transfer. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["law of demeter", "law of", "of demeter", "data structure", "object design", "encapsulation", "data abstraction", "least knowledge", "message chain", "object navigation", "objects and data structures", "clean code"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "city = order.customer.address.city", "typescript": "const city = order.customer.address.city;"}, "display_text": "CC-106 Law Of Demeter\nTopic: Objects and Data Structures\nAliases: law of demeter, law of, of demeter, data structure, object design, encapsulation, data abstraction, least knowledge, message chain, object navigation, objects and data structures, clean code\nProblem: Code has a clean-code risk related to law of demeter: Talk to immediate collaborators instead of navigating through object internals. Search terms that should match this issue include law of demeter, law of, of demeter, data structure, object design.\nUse when: Use this pattern when planning or reviewing code where talk to immediate collaborators instead of navigating through object internals. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst city = order.shippingCity();\nGood Python:\ncity = order.shipping_city()\nBad TypeScript:\nconst city = order.customer.address.city;\nBad Python:\ncity = order.customer.address.city\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-106: Law Of Demeter. Topic: Objects and Data Structures. Rule family: objects_data. Aliases and smell terms: law of demeter, law of, of demeter, data structure, object design, encapsulation, data abstraction, least knowledge, message chain, object navigation, objects and data structures, clean code. Problem: Code has a clean-code risk related to law of demeter: Talk to immediate collaborators instead of navigating through object internals. Search terms that should match this issue include law of demeter, law of, of demeter, data structure, object design. Use when: Use this pattern when planning or reviewing code where talk to immediate collaborators instead of navigating through object internals. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const city = order.shippingCity(); Good Python example: city = order.shipping_city() Bad TypeScript example: const city = order.customer.address.city; Bad Python example: city = order.customer.address.city", "good_examples": {"python": "city = order.shipping_city()", "typescript": "const city = order.shippingCity();"}, "id": "CC-106", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to law of demeter: Talk to immediate collaborators instead of navigating through object internals. Search terms that should match this issue include law of demeter, law of, of demeter, data structure, object design.", "rule_family": "objects_data", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Law Of Demeter", "topic": "Objects and Data Structures", "use_when": "Use this pattern when planning or reviewing code where talk to immediate collaborators instead of navigating through object internals. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["train wrecks", "data structure", "object design", "encapsulation", "data abstraction", "train wreck", "message chain", "deep property chain", "transitive navigation", "objects and data structures", "clean code", "code smell"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "city = order.customer.address.city", "typescript": "const city = order.customer.address.city;"}, "display_text": "CC-107 Train Wrecks\nTopic: Objects and Data Structures\nAliases: train wrecks, data structure, object design, encapsulation, data abstraction, train wreck, message chain, deep property chain, transitive navigation, objects and data structures, clean code, code smell\nProblem: Code has a clean-code risk related to train wrecks: Replace long chains with a named method on the owning concept. Search terms that should match this issue include train wrecks, data structure, object design, encapsulation, data abstraction.\nUse when: Use this pattern when planning or reviewing code where replace long chains with a named method on the owning concept. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst owner = project.ownerEmail();\nGood Python:\nowner = project.owner_email()\nBad TypeScript:\nconst city = order.customer.address.city;\nBad Python:\ncity = order.customer.address.city\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-107: Train Wrecks. Topic: Objects and Data Structures. Rule family: objects_data. Aliases and smell terms: train wrecks, data structure, object design, encapsulation, data abstraction, train wreck, message chain, deep property chain, transitive navigation, objects and data structures, clean code, code smell. Problem: Code has a clean-code risk related to train wrecks: Replace long chains with a named method on the owning concept. Search terms that should match this issue include train wrecks, data structure, object design, encapsulation, data abstraction. Use when: Use this pattern when planning or reviewing code where replace long chains with a named method on the owning concept. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const owner = project.ownerEmail(); Good Python example: owner = project.owner_email() Bad TypeScript example: const city = order.customer.address.city; Bad Python example: city = order.customer.address.city", "good_examples": {"python": "owner = project.owner_email()", "typescript": "const owner = project.ownerEmail();"}, "id": "CC-107", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to train wrecks: Replace long chains with a named method on the owning concept. Search terms that should match this issue include train wrecks, data structure, object design, encapsulation, data abstraction.", "rule_family": "objects_data", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Train Wrecks", "topic": "Objects and Data Structures", "use_when": "Use this pattern when planning or reviewing code where replace long chains with a named method on the owning concept. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["hybrids", "data structure", "object design", "encapsulation", "data abstraction", "objects and data structures", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-108 Hybrids\nTopic: Objects and Data Structures\nAliases: hybrids, data structure, object design, encapsulation, data abstraction, objects and data structures, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to hybrids: Avoid types that expose raw data while also pretending to protect behavior. Search terms that should match this issue include hybrids, data structure, object design, encapsulation, data abstraction.\nUse when: Use this pattern when planning or reviewing code where avoid types that expose raw data while also pretending to protect behavior. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst status = invoice.currentStatus();\nGood Python:\nstatus = invoice.current_status()\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-108: Hybrids. Topic: Objects and Data Structures. Rule family: objects_data. Aliases and smell terms: hybrids, data structure, object design, encapsulation, data abstraction, objects and data structures, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to hybrids: Avoid types that expose raw data while also pretending to protect behavior. Search terms that should match this issue include hybrids, data structure, object design, encapsulation, data abstraction. Use when: Use this pattern when planning or reviewing code where avoid types that expose raw data while also pretending to protect behavior. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const status = invoice.currentStatus(); Good Python example: status = invoice.current_status() Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "status = invoice.current_status()", "typescript": "const status = invoice.currentStatus();"}, "id": "CC-108", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to hybrids: Avoid types that expose raw data while also pretending to protect behavior. Search terms that should match this issue include hybrids, data structure, object design, encapsulation, data abstraction.", "rule_family": "objects_data", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Hybrids", "topic": "Objects and Data Structures", "use_when": "Use this pattern when planning or reviewing code where avoid types that expose raw data while also pretending to protect behavior. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["hiding structure", "data structure", "object design", "encapsulation", "data abstraction", "objects and data structures", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-109 Hiding Structure\nTopic: Objects and Data Structures\nAliases: hiding structure, data structure, object design, encapsulation, data abstraction, objects and data structures, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to hiding structure: Ask an object to do work rather than exposing its nested structure. Search terms that should match this issue include hiding structure, data structure, object design, encapsulation, data abstraction.\nUse when: Use this pattern when planning or reviewing code where ask an object to do work rather than exposing its nested structure. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\norder.scheduleShipment(carrier);\nGood Python:\norder.schedule_shipment(carrier)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-109: Hiding Structure. Topic: Objects and Data Structures. Rule family: objects_data. Aliases and smell terms: hiding structure, data structure, object design, encapsulation, data abstraction, objects and data structures, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to hiding structure: Ask an object to do work rather than exposing its nested structure. Search terms that should match this issue include hiding structure, data structure, object design, encapsulation, data abstraction. Use when: Use this pattern when planning or reviewing code where ask an object to do work rather than exposing its nested structure. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: order.scheduleShipment(carrier); Good Python example: order.schedule_shipment(carrier) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "order.schedule_shipment(carrier)", "typescript": "order.scheduleShipment(carrier);"}, "id": "CC-109", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to hiding structure: Ask an object to do work rather than exposing its nested structure. Search terms that should match this issue include hiding structure, data structure, object design, encapsulation, data abstraction.", "rule_family": "objects_data", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Hiding Structure", "topic": "Objects and Data Structures", "use_when": "Use this pattern when planning or reviewing code where ask an object to do work rather than exposing its nested structure. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["data transfer objects", "data transfer", "transfer objects", "data structure", "object design", "encapsulation", "data abstraction", "objects and data structures", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-110 Data Transfer Objects\nTopic: Objects and Data Structures\nAliases: data transfer objects, data transfer, transfer objects, data structure, object design, encapsulation, data abstraction, objects and data structures, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to data transfer objects: Use DTOs as simple boundary shapes without domain behavior. Search terms that should match this issue include data transfer objects, data transfer, transfer objects, data structure, object design.\nUse when: Use this pattern when planning or reviewing code where use DTOs as simple boundary shapes without domain behavior. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\ntype CreateUserRequest = { email: string; name: string };\nGood Python:\nclass CreateUserRequest(TypedDict):\n    email: str\n    name: str\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-110: Data Transfer Objects. Topic: Objects and Data Structures. Rule family: objects_data. Aliases and smell terms: data transfer objects, data transfer, transfer objects, data structure, object design, encapsulation, data abstraction, objects and data structures, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to data transfer objects: Use DTOs as simple boundary shapes without domain behavior. Search terms that should match this issue include data transfer objects, data transfer, transfer objects, data structure, object design. Use when: Use this pattern when planning or reviewing code where use DTOs as simple boundary shapes without domain behavior. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: type CreateUserRequest = { email: string; name: string }; Good Python example: class CreateUserRequest(TypedDict):\n    email: str\n    name: str Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "class CreateUserRequest(TypedDict):\n    email: str\n    name: str", "typescript": "type CreateUserRequest = { email: string; name: string };"}, "id": "CC-110", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to data transfer objects: Use DTOs as simple boundary shapes without domain behavior. Search terms that should match this issue include data transfer objects, data transfer, transfer objects, data structure, object design.", "rule_family": "objects_data", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Data Transfer Objects", "topic": "Objects and Data Structures", "use_when": "Use this pattern when planning or reviewing code where use DTOs as simple boundary shapes without domain behavior. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["active record", "data structure", "object design", "encapsulation", "data abstraction", "objects and data structures", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-111 Active Record\nTopic: Objects and Data Structures\nAliases: active record, data structure, object design, encapsulation, data abstraction, objects and data structures, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to active record: Keep persistence records separate from richer domain policy when behavior grows. Search terms that should match this issue include active record, data structure, object design, encapsulation, data abstraction.\nUse when: Use this pattern when planning or reviewing code where keep persistence records separate from richer domain policy when behavior grows. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst customer = Customer.fromRecord(record);\nGood Python:\ncustomer = Customer.from_record(record)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-111: Active Record. Topic: Objects and Data Structures. Rule family: objects_data. Aliases and smell terms: active record, data structure, object design, encapsulation, data abstraction, objects and data structures, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to active record: Keep persistence records separate from richer domain policy when behavior grows. Search terms that should match this issue include active record, data structure, object design, encapsulation, data abstraction. Use when: Use this pattern when planning or reviewing code where keep persistence records separate from richer domain policy when behavior grows. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const customer = Customer.fromRecord(record); Good Python example: customer = Customer.from_record(record) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "customer = Customer.from_record(record)", "typescript": "const customer = Customer.fromRecord(record);"}, "id": "CC-111", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to active record: Keep persistence records separate from richer domain policy when behavior grows. Search terms that should match this issue include active record, data structure, object design, encapsulation, data abstraction.", "rule_family": "objects_data", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Active Record", "topic": "Objects and Data Structures", "use_when": "Use this pattern when planning or reviewing code where keep persistence records separate from richer domain policy when behavior grows. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["use exceptions rather than return codes", "use exceptions", "return codes", "error handling", "exception design", "failure boundary", "error contract", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract.", "bad_examples": {"python": "return {'ok': False, 'error_code': 'FAILED'}", "typescript": "return { ok: false, errorCode: 'FAILED' };"}, "display_text": "CC-112 Use Exceptions Rather Than Return Codes\nTopic: Error Handling\nAliases: use exceptions rather than return codes, use exceptions, return codes, error handling, exception design, failure boundary, error contract, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to use exceptions rather than return codes: Represent failure explicitly so callers cannot ignore it. Search terms that should match this issue include use exceptions rather than return codes, use exceptions, return codes, error handling, exception design.\nUse when: Use this pattern when planning or reviewing code where represent failure explicitly so callers cannot ignore it. It is especially relevant when callers need a clear failure contract.\nAvoid when: Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract.\nGood TypeScript:\nif (!user) throw new UserNotFoundError(userId);\nGood Python:\nif user is None:\n    raise UserNotFoundError(user_id)\nBad TypeScript:\nreturn { ok: false, errorCode: 'FAILED' };\nBad Python:\nreturn {'ok': False, 'error_code': 'FAILED'}\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-112: Use Exceptions Rather Than Return Codes. Topic: Error Handling. Rule family: error_handling. Aliases and smell terms: use exceptions rather than return codes, use exceptions, return codes, error handling, exception design, failure boundary, error contract, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to use exceptions rather than return codes: Represent failure explicitly so callers cannot ignore it. Search terms that should match this issue include use exceptions rather than return codes, use exceptions, return codes, error handling, exception design. Use when: Use this pattern when planning or reviewing code where represent failure explicitly so callers cannot ignore it. It is especially relevant when callers need a clear failure contract. Avoid when: Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: if (!user) throw new UserNotFoundError(userId); Good Python example: if user is None:\n    raise UserNotFoundError(user_id) Bad TypeScript example: return { ok: false, errorCode: 'FAILED' }; Bad Python example: return {'ok': False, 'error_code': 'FAILED'}", "good_examples": {"python": "if user is None:\n    raise UserNotFoundError(user_id)", "typescript": "if (!user) throw new UserNotFoundError(userId);"}, "id": "CC-112", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to use exceptions rather than return codes: Represent failure explicitly so callers cannot ignore it. Search terms that should match this issue include use exceptions rather than return codes, use exceptions, return codes, error handling, exception design.", "rule_family": "error_handling", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Use Exceptions Rather Than Return Codes", "topic": "Error Handling", "use_when": "Use this pattern when planning or reviewing code where represent failure explicitly so callers cannot ignore it. It is especially relevant when callers need a clear failure contract."}
+{"aliases": ["write try catch finally first", "write try", "finally first", "error handling", "exception design", "failure boundary", "error contract", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract.", "bad_examples": {"python": "return {'ok': False, 'error_code': 'FAILED'}", "typescript": "return { ok: false, errorCode: 'FAILED' };"}, "display_text": "CC-113 Write Try Catch Finally First\nTopic: Error Handling\nAliases: write try catch finally first, write try, finally first, error handling, exception design, failure boundary, error contract, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to write try catch finally first: Define the failure boundary before filling in risky work. Search terms that should match this issue include write try catch finally first, write try, finally first, error handling, exception design.\nUse when: Use this pattern when planning or reviewing code where define the failure boundary before filling in risky work. It is especially relevant when callers need a clear failure contract.\nAvoid when: Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract.\nGood TypeScript:\ntry {\n  await importFile(file);\n} finally {\n  await file.close();\n}\nGood Python:\nwith open_import_file(path) as file:\n    import_file(file)\nBad TypeScript:\nreturn { ok: false, errorCode: 'FAILED' };\nBad Python:\nreturn {'ok': False, 'error_code': 'FAILED'}\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-113: Write Try Catch Finally First. Topic: Error Handling. Rule family: error_handling. Aliases and smell terms: write try catch finally first, write try, finally first, error handling, exception design, failure boundary, error contract, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to write try catch finally first: Define the failure boundary before filling in risky work. Search terms that should match this issue include write try catch finally first, write try, finally first, error handling, exception design. Use when: Use this pattern when planning or reviewing code where define the failure boundary before filling in risky work. It is especially relevant when callers need a clear failure contract. Avoid when: Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: try {\n  await importFile(file);\n} finally {\n  await file.close();\n} Good Python example: with open_import_file(path) as file:\n    import_file(file) Bad TypeScript example: return { ok: false, errorCode: 'FAILED' }; Bad Python example: return {'ok': False, 'error_code': 'FAILED'}", "good_examples": {"python": "with open_import_file(path) as file:\n    import_file(file)", "typescript": "try {\n  await importFile(file);\n} finally {\n  await file.close();\n}"}, "id": "CC-113", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to write try catch finally first: Define the failure boundary before filling in risky work. Search terms that should match this issue include write try catch finally first, write try, finally first, error handling, exception design.", "rule_family": "error_handling", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Write Try Catch Finally First", "topic": "Error Handling", "use_when": "Use this pattern when planning or reviewing code where define the failure boundary before filling in risky work. It is especially relevant when callers need a clear failure contract."}
+{"aliases": ["use unchecked exceptions", "use unchecked", "unchecked exceptions", "error handling", "exception design", "failure boundary", "error contract", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract.", "bad_examples": {"python": "return {'ok': False, 'error_code': 'FAILED'}", "typescript": "return { ok: false, errorCode: 'FAILED' };"}, "display_text": "CC-114 Use Unchecked Exceptions\nTopic: Error Handling\nAliases: use unchecked exceptions, use unchecked, unchecked exceptions, error handling, exception design, failure boundary, error contract, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to use unchecked exceptions: Keep ordinary call chains free from plumbing error codes. Search terms that should match this issue include use unchecked exceptions, use unchecked, unchecked exceptions, error handling, exception design.\nUse when: Use this pattern when planning or reviewing code where keep ordinary call chains free from plumbing error codes. It is especially relevant when callers need a clear failure contract.\nAvoid when: Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract.\nGood TypeScript:\nthrow new PaymentDeclinedError(paymentId);\nGood Python:\nraise PaymentDeclinedError(payment_id)\nBad TypeScript:\nreturn { ok: false, errorCode: 'FAILED' };\nBad Python:\nreturn {'ok': False, 'error_code': 'FAILED'}\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-114: Use Unchecked Exceptions. Topic: Error Handling. Rule family: error_handling. Aliases and smell terms: use unchecked exceptions, use unchecked, unchecked exceptions, error handling, exception design, failure boundary, error contract, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to use unchecked exceptions: Keep ordinary call chains free from plumbing error codes. Search terms that should match this issue include use unchecked exceptions, use unchecked, unchecked exceptions, error handling, exception design. Use when: Use this pattern when planning or reviewing code where keep ordinary call chains free from plumbing error codes. It is especially relevant when callers need a clear failure contract. Avoid when: Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: throw new PaymentDeclinedError(paymentId); Good Python example: raise PaymentDeclinedError(payment_id) Bad TypeScript example: return { ok: false, errorCode: 'FAILED' }; Bad Python example: return {'ok': False, 'error_code': 'FAILED'}", "good_examples": {"python": "raise PaymentDeclinedError(payment_id)", "typescript": "throw new PaymentDeclinedError(paymentId);"}, "id": "CC-114", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to use unchecked exceptions: Keep ordinary call chains free from plumbing error codes. Search terms that should match this issue include use unchecked exceptions, use unchecked, unchecked exceptions, error handling, exception design.", "rule_family": "error_handling", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Use Unchecked Exceptions", "topic": "Error Handling", "use_when": "Use this pattern when planning or reviewing code where keep ordinary call chains free from plumbing error codes. It is especially relevant when callers need a clear failure contract."}
+{"aliases": ["provide context with exceptions", "provide context", "with exceptions", "error handling", "exception design", "failure boundary", "error contract", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract.", "bad_examples": {"python": "return {'ok': False, 'error_code': 'FAILED'}", "typescript": "return { ok: false, errorCode: 'FAILED' };"}, "display_text": "CC-115 Provide Context With Exceptions\nTopic: Error Handling\nAliases: provide context with exceptions, provide context, with exceptions, error handling, exception design, failure boundary, error contract, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to provide context with exceptions: Attach useful identifiers and operation context to failures. Search terms that should match this issue include provide context with exceptions, provide context, with exceptions, error handling, exception design.\nUse when: Use this pattern when planning or reviewing code where attach useful identifiers and operation context to failures. It is especially relevant when callers need a clear failure contract.\nAvoid when: Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract.\nGood TypeScript:\nthrow new QuoteLoadError(pair, { cause: error });\nGood Python:\nraise QuoteLoadError(pair) from error\nBad TypeScript:\nreturn { ok: false, errorCode: 'FAILED' };\nBad Python:\nreturn {'ok': False, 'error_code': 'FAILED'}\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-115: Provide Context With Exceptions. Topic: Error Handling. Rule family: error_handling. Aliases and smell terms: provide context with exceptions, provide context, with exceptions, error handling, exception design, failure boundary, error contract, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to provide context with exceptions: Attach useful identifiers and operation context to failures. Search terms that should match this issue include provide context with exceptions, provide context, with exceptions, error handling, exception design. Use when: Use this pattern when planning or reviewing code where attach useful identifiers and operation context to failures. It is especially relevant when callers need a clear failure contract. Avoid when: Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: throw new QuoteLoadError(pair, { cause: error }); Good Python example: raise QuoteLoadError(pair) from error Bad TypeScript example: return { ok: false, errorCode: 'FAILED' }; Bad Python example: return {'ok': False, 'error_code': 'FAILED'}", "good_examples": {"python": "raise QuoteLoadError(pair) from error", "typescript": "throw new QuoteLoadError(pair, { cause: error });"}, "id": "CC-115", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to provide context with exceptions: Attach useful identifiers and operation context to failures. Search terms that should match this issue include provide context with exceptions, provide context, with exceptions, error handling, exception design.", "rule_family": "error_handling", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Provide Context With Exceptions", "topic": "Error Handling", "use_when": "Use this pattern when planning or reviewing code where attach useful identifiers and operation context to failures. It is especially relevant when callers need a clear failure contract."}
+{"aliases": ["define exception classes by caller needs", "define exception", "caller needs", "class smell", "cohesion", "single responsibility", "class design", "error handling", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-116 Define Exception Classes By Caller Needs\nTopic: Error Handling\nAliases: define exception classes by caller needs, define exception, caller needs, class smell, cohesion, single responsibility, class design, error handling, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to define exception classes by caller needs: Group errors by what callers can do about them. Search terms that should match this issue include define exception classes by caller needs, define exception, caller needs, class smell, cohesion.\nUse when: Use this pattern when planning or reviewing code where group errors by what callers can do about them. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\ncatch (error) {\n  if (error instanceof RetryablePaymentError) retry();\n}\nGood Python:\nexcept RetryablePaymentError:\n    retry()\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-116: Define Exception Classes By Caller Needs. Topic: Error Handling. Rule family: classes. Aliases and smell terms: define exception classes by caller needs, define exception, caller needs, class smell, cohesion, single responsibility, class design, error handling, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to define exception classes by caller needs: Group errors by what callers can do about them. Search terms that should match this issue include define exception classes by caller needs, define exception, caller needs, class smell, cohesion. Use when: Use this pattern when planning or reviewing code where group errors by what callers can do about them. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: catch (error) {\n  if (error instanceof RetryablePaymentError) retry();\n} Good Python example: except RetryablePaymentError:\n    retry() Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "except RetryablePaymentError:\n    retry()", "typescript": "catch (error) {\n  if (error instanceof RetryablePaymentError) retry();\n}"}, "id": "CC-116", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to define exception classes by caller needs: Group errors by what callers can do about them. Search terms that should match this issue include define exception classes by caller needs, define exception, caller needs, class smell, cohesion.", "rule_family": "classes", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Define Exception Classes By Caller Needs", "topic": "Error Handling", "use_when": "Use this pattern when planning or reviewing code where group errors by what callers can do about them. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["define the normal flow", "define the", "normal flow", "error handling", "exception design", "failure boundary", "error contract", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract.", "bad_examples": {"python": "return {'ok': False, 'error_code': 'FAILED'}", "typescript": "return { ok: false, errorCode: 'FAILED' };"}, "display_text": "CC-117 Define The Normal Flow\nTopic: Error Handling\nAliases: define the normal flow, define the, normal flow, error handling, exception design, failure boundary, error contract, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to define the normal flow: Use a normal object or policy when an expected case is not exceptional. Search terms that should match this issue include define the normal flow, define the, normal flow, error handling, exception design.\nUse when: Use this pattern when planning or reviewing code where use a normal object or policy when an expected case is not exceptional. It is especially relevant when callers need a clear failure contract.\nAvoid when: Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract.\nGood TypeScript:\nconst plan = customer.plan ?? FreePlan.default();\nGood Python:\nplan = customer.plan or FreePlan.default()\nBad TypeScript:\nreturn { ok: false, errorCode: 'FAILED' };\nBad Python:\nreturn {'ok': False, 'error_code': 'FAILED'}\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-117: Define The Normal Flow. Topic: Error Handling. Rule family: error_handling. Aliases and smell terms: define the normal flow, define the, normal flow, error handling, exception design, failure boundary, error contract, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to define the normal flow: Use a normal object or policy when an expected case is not exceptional. Search terms that should match this issue include define the normal flow, define the, normal flow, error handling, exception design. Use when: Use this pattern when planning or reviewing code where use a normal object or policy when an expected case is not exceptional. It is especially relevant when callers need a clear failure contract. Avoid when: Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const plan = customer.plan ?? FreePlan.default(); Good Python example: plan = customer.plan or FreePlan.default() Bad TypeScript example: return { ok: false, errorCode: 'FAILED' }; Bad Python example: return {'ok': False, 'error_code': 'FAILED'}", "good_examples": {"python": "plan = customer.plan or FreePlan.default()", "typescript": "const plan = customer.plan ?? FreePlan.default();"}, "id": "CC-117", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to define the normal flow: Use a normal object or policy when an expected case is not exceptional. Search terms that should match this issue include define the normal flow, define the, normal flow, error handling, exception design.", "rule_family": "error_handling", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Define The Normal Flow", "topic": "Error Handling", "use_when": "Use this pattern when planning or reviewing code where use a normal object or policy when an expected case is not exceptional. It is especially relevant when callers need a clear failure contract."}
+{"aliases": ["do not return null", "do not", "return null", "error handling", "exception design", "failure boundary", "error contract", "null handling", "none handling", "missing value", "absence contract", "clean code"], "avoid_when": "Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract.", "bad_examples": {"python": "return invoice or None", "typescript": "return invoice ?? null;"}, "display_text": "CC-118 Do Not Return Null\nTopic: Error Handling\nAliases: do not return null, do not, return null, error handling, exception design, failure boundary, error contract, null handling, none handling, missing value, absence contract, clean code\nProblem: Code has a clean-code risk related to do not return null: Return empty collections or explicit option types instead of null surprises. Search terms that should match this issue include do not return null, do not, return null, error handling, exception design.\nUse when: Use this pattern when planning or reviewing code where return empty collections or explicit option types instead of null surprises. It is especially relevant when callers need a clear failure contract.\nAvoid when: Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract.\nGood TypeScript:\nreturn ordersByCustomer.get(customerId) ?? [];\nGood Python:\nreturn orders_by_customer.get(customer_id, [])\nBad TypeScript:\nreturn invoice ?? null;\nBad Python:\nreturn invoice or None\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: high", "embedding_text": "Clean code pattern CC-118: Do Not Return Null. Topic: Error Handling. Rule family: error_handling. Aliases and smell terms: do not return null, do not, return null, error handling, exception design, failure boundary, error contract, null handling, none handling, missing value, absence contract, clean code. Problem: Code has a clean-code risk related to do not return null: Return empty collections or explicit option types instead of null surprises. Search terms that should match this issue include do not return null, do not, return null, error handling, exception design. Use when: Use this pattern when planning or reviewing code where return empty collections or explicit option types instead of null surprises. It is especially relevant when callers need a clear failure contract. Avoid when: Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: return ordersByCustomer.get(customerId) ?? []; Good Python example: return orders_by_customer.get(customer_id, []) Bad TypeScript example: return invoice ?? null; Bad Python example: return invoice or None", "good_examples": {"python": "return orders_by_customer.get(customer_id, [])", "typescript": "return ordersByCustomer.get(customerId) ?? [];"}, "id": "CC-118", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "high", "problem": "Code has a clean-code risk related to do not return null: Return empty collections or explicit option types instead of null surprises. Search terms that should match this issue include do not return null, do not, return null, error handling, exception design.", "rule_family": "error_handling", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Do Not Return Null", "topic": "Error Handling", "use_when": "Use this pattern when planning or reviewing code where return empty collections or explicit option types instead of null surprises. It is especially relevant when callers need a clear failure contract."}
+{"aliases": ["do not pass null", "do not", "pass null", "error handling", "exception design", "failure boundary", "error contract", "null handling", "none handling", "missing value", "absence contract", "clean code"], "avoid_when": "Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract.", "bad_examples": {"python": "return invoice or None", "typescript": "return invoice ?? null;"}, "display_text": "CC-119 Do Not Pass Null\nTopic: Error Handling\nAliases: do not pass null, do not, pass null, error handling, exception design, failure boundary, error contract, null handling, none handling, missing value, absence contract, clean code\nProblem: Code has a clean-code risk related to do not pass null: Require real values at boundaries and fail early for absent dependencies. Search terms that should match this issue include do not pass null, do not, pass null, error handling, exception design.\nUse when: Use this pattern when planning or reviewing code where require real values at boundaries and fail early for absent dependencies. It is especially relevant when callers need a clear failure contract.\nAvoid when: Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract.\nGood TypeScript:\nsubmitOrder(requireCustomer(customer));\nGood Python:\nsubmit_order(require_customer(customer))\nBad TypeScript:\nreturn invoice ?? null;\nBad Python:\nreturn invoice or None\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: high", "embedding_text": "Clean code pattern CC-119: Do Not Pass Null. Topic: Error Handling. Rule family: error_handling. Aliases and smell terms: do not pass null, do not, pass null, error handling, exception design, failure boundary, error contract, null handling, none handling, missing value, absence contract, clean code. Problem: Code has a clean-code risk related to do not pass null: Require real values at boundaries and fail early for absent dependencies. Search terms that should match this issue include do not pass null, do not, pass null, error handling, exception design. Use when: Use this pattern when planning or reviewing code where require real values at boundaries and fail early for absent dependencies. It is especially relevant when callers need a clear failure contract. Avoid when: Avoid changing error style when the surrounding API has a deliberate return-value or result-object contract. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: submitOrder(requireCustomer(customer)); Good Python example: submit_order(require_customer(customer)) Bad TypeScript example: return invoice ?? null; Bad Python example: return invoice or None", "good_examples": {"python": "submit_order(require_customer(customer))", "typescript": "submitOrder(requireCustomer(customer));"}, "id": "CC-119", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "high", "problem": "Code has a clean-code risk related to do not pass null: Require real values at boundaries and fail early for absent dependencies. Search terms that should match this issue include do not pass null, do not, pass null, error handling, exception design.", "rule_family": "error_handling", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Do Not Pass Null", "topic": "Error Handling", "use_when": "Use this pattern when planning or reviewing code where require real values at boundaries and fail early for absent dependencies. It is especially relevant when callers need a clear failure contract."}
+{"aliases": ["using third-party code", "using third party code", "using third", "party code", "boundary design", "adapter", "third party code", "integration seam", "boundaries", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-120 Using Third-Party Code\nTopic: Boundaries\nAliases: using third-party code, using third party code, using third, party code, boundary design, adapter, third party code, integration seam, boundaries, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to using third-party code: Wrap third-party APIs behind app-shaped adapters. Search terms that should match this issue include using third-party code, using third party code, using third, party code, boundary design.\nUse when: Use this pattern when planning or reviewing code where wrap third-party APIs behind app-shaped adapters. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nemailSender.sendWelcomeEmail(customer);\nGood Python:\nemail_sender.send_welcome_email(customer)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-120: Using Third-Party Code. Topic: Boundaries. Rule family: boundaries. Aliases and smell terms: using third-party code, using third party code, using third, party code, boundary design, adapter, third party code, integration seam, boundaries, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to using third-party code: Wrap third-party APIs behind app-shaped adapters. Search terms that should match this issue include using third-party code, using third party code, using third, party code, boundary design. Use when: Use this pattern when planning or reviewing code where wrap third-party APIs behind app-shaped adapters. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: emailSender.sendWelcomeEmail(customer); Good Python example: email_sender.send_welcome_email(customer) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "email_sender.send_welcome_email(customer)", "typescript": "emailSender.sendWelcomeEmail(customer);"}, "id": "CC-120", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to using third-party code: Wrap third-party APIs behind app-shaped adapters. Search terms that should match this issue include using third-party code, using third party code, using third, party code, boundary design.", "rule_family": "boundaries", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Using Third-Party Code", "topic": "Boundaries", "use_when": "Use this pattern when planning or reviewing code where wrap third-party APIs behind app-shaped adapters. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["exploring and learning boundaries", "exploring and", "learning boundaries", "boundary design", "adapter", "third party code", "integration seam", "boundaries", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-121 Exploring And Learning Boundaries\nTopic: Boundaries\nAliases: exploring and learning boundaries, exploring and, learning boundaries, boundary design, adapter, third party code, integration seam, boundaries, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to exploring and learning boundaries: Write small experiments to learn an external API before embedding it deeply. Search terms that should match this issue include exploring and learning boundaries, exploring and, learning boundaries, boundary design, adapter.\nUse when: Use this pattern when planning or reviewing code where write small experiments to learn an external API before embedding it deeply. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nexpect(parseProviderDate(sample)).toEqual(expectedDate);\nGood Python:\nassert parse_provider_date(sample) == expected_date\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-121: Exploring And Learning Boundaries. Topic: Boundaries. Rule family: boundaries. Aliases and smell terms: exploring and learning boundaries, exploring and, learning boundaries, boundary design, adapter, third party code, integration seam, boundaries, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to exploring and learning boundaries: Write small experiments to learn an external API before embedding it deeply. Search terms that should match this issue include exploring and learning boundaries, exploring and, learning boundaries, boundary design, adapter. Use when: Use this pattern when planning or reviewing code where write small experiments to learn an external API before embedding it deeply. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: expect(parseProviderDate(sample)).toEqual(expectedDate); Good Python example: assert parse_provider_date(sample) == expected_date Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "assert parse_provider_date(sample) == expected_date", "typescript": "expect(parseProviderDate(sample)).toEqual(expectedDate);"}, "id": "CC-121", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to exploring and learning boundaries: Write small experiments to learn an external API before embedding it deeply. Search terms that should match this issue include exploring and learning boundaries, exploring and, learning boundaries, boundary design, adapter.", "rule_family": "boundaries", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Exploring And Learning Boundaries", "topic": "Boundaries", "use_when": "Use this pattern when planning or reviewing code where write small experiments to learn an external API before embedding it deeply. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["learning log4j", "boundary design", "adapter", "third party code", "integration seam", "boundaries", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-122 Learning log4j\nTopic: Boundaries\nAliases: learning log4j, boundary design, adapter, third party code, integration seam, boundaries, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to learning log4j: Capture library behavior in focused learning tests. Search terms that should match this issue include learning log4j, boundary design, adapter, third party code, integration seam.\nUse when: Use this pattern when planning or reviewing code where capture library behavior in focused learning tests. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nexpect(logger.levelFor('billing')).toBe('info');\nGood Python:\nassert logger.level_for('billing') == 'info'\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-122: Learning log4j. Topic: Boundaries. Rule family: boundaries. Aliases and smell terms: learning log4j, boundary design, adapter, third party code, integration seam, boundaries, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to learning log4j: Capture library behavior in focused learning tests. Search terms that should match this issue include learning log4j, boundary design, adapter, third party code, integration seam. Use when: Use this pattern when planning or reviewing code where capture library behavior in focused learning tests. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: expect(logger.levelFor('billing')).toBe('info'); Good Python example: assert logger.level_for('billing') == 'info' Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "assert logger.level_for('billing') == 'info'", "typescript": "expect(logger.levelFor('billing')).toBe('info');"}, "id": "CC-122", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to learning log4j: Capture library behavior in focused learning tests. Search terms that should match this issue include learning log4j, boundary design, adapter, third party code, integration seam.", "rule_family": "boundaries", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Learning log4j", "topic": "Boundaries", "use_when": "Use this pattern when planning or reviewing code where capture library behavior in focused learning tests. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["learning tests are better than free", "learning tests", "than free", "unit test", "test smell", "test design", "test quality", "boundaries", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-123 Learning Tests Are Better Than Free\nTopic: Boundaries\nAliases: learning tests are better than free, learning tests, than free, unit test, test smell, test design, test quality, boundaries, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to learning tests are better than free: Keep learning tests as upgrade alarms for third-party behavior. Search terms that should match this issue include learning tests are better than free, learning tests, than free, unit test, test smell.\nUse when: Use this pattern when planning or reviewing code where keep learning tests as upgrade alarms for third-party behavior. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nit('parses provider timeout errors', () => expect(parseError(timeout)).toEqual(retryable));\nGood Python:\ndef test_parses_provider_timeout_errors():\n    assert parse_error(timeout) == retryable\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-123: Learning Tests Are Better Than Free. Topic: Boundaries. Rule family: tests. Aliases and smell terms: learning tests are better than free, learning tests, than free, unit test, test smell, test design, test quality, boundaries, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to learning tests are better than free: Keep learning tests as upgrade alarms for third-party behavior. Search terms that should match this issue include learning tests are better than free, learning tests, than free, unit test, test smell. Use when: Use this pattern when planning or reviewing code where keep learning tests as upgrade alarms for third-party behavior. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: it('parses provider timeout errors', () => expect(parseError(timeout)).toEqual(retryable)); Good Python example: def test_parses_provider_timeout_errors():\n    assert parse_error(timeout) == retryable Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "def test_parses_provider_timeout_errors():\n    assert parse_error(timeout) == retryable", "typescript": "it('parses provider timeout errors', () => expect(parseError(timeout)).toEqual(retryable));"}, "id": "CC-123", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to learning tests are better than free: Keep learning tests as upgrade alarms for third-party behavior. Search terms that should match this issue include learning tests are better than free, learning tests, than free, unit test, test smell.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Learning Tests Are Better Than Free", "topic": "Boundaries", "use_when": "Use this pattern when planning or reviewing code where keep learning tests as upgrade alarms for third-party behavior. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["using code that does not yet exist", "using code", "yet exist", "boundary design", "adapter", "third party code", "integration seam", "boundaries", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-124 Using Code That Does Not Yet Exist\nTopic: Boundaries\nAliases: using code that does not yet exist, using code, yet exist, boundary design, adapter, third party code, integration seam, boundaries, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to using code that does not yet exist: Define the interface you wish you had, then adapt the eventual dependency to it. Search terms that should match this issue include using code that does not yet exist, using code, yet exist, boundary design, adapter.\nUse when: Use this pattern when planning or reviewing code where define the interface you wish you had, then adapt the eventual dependency to it. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\ninterface MarketData { latestPrice(pair: Pair): Promise<Money>; }\nGood Python:\nclass MarketData(Protocol):\n    def latest_price(self, pair: Pair) -> Money: ...\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-124: Using Code That Does Not Yet Exist. Topic: Boundaries. Rule family: boundaries. Aliases and smell terms: using code that does not yet exist, using code, yet exist, boundary design, adapter, third party code, integration seam, boundaries, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to using code that does not yet exist: Define the interface you wish you had, then adapt the eventual dependency to it. Search terms that should match this issue include using code that does not yet exist, using code, yet exist, boundary design, adapter. Use when: Use this pattern when planning or reviewing code where define the interface you wish you had, then adapt the eventual dependency to it. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: interface MarketData { latestPrice(pair: Pair): Promise<Money>; } Good Python example: class MarketData(Protocol):\n    def latest_price(self, pair: Pair) -> Money: ... Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "class MarketData(Protocol):\n    def latest_price(self, pair: Pair) -> Money: ...", "typescript": "interface MarketData { latestPrice(pair: Pair): Promise<Money>; }"}, "id": "CC-124", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to using code that does not yet exist: Define the interface you wish you had, then adapt the eventual dependency to it. Search terms that should match this issue include using code that does not yet exist, using code, yet exist, boundary design, adapter.", "rule_family": "boundaries", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Using Code That Does Not Yet Exist", "topic": "Boundaries", "use_when": "Use this pattern when planning or reviewing code where define the interface you wish you had, then adapt the eventual dependency to it. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["clean boundaries", "boundary design", "adapter", "third party code", "integration seam", "boundaries", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-125 Clean Boundaries\nTopic: Boundaries\nAliases: clean boundaries, boundary design, adapter, third party code, integration seam, boundaries, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to clean boundaries: Keep boundary translation in one place. Search terms that should match this issue include clean boundaries, boundary design, adapter, third party code, integration seam.\nUse when: Use this pattern when planning or reviewing code where keep boundary translation in one place. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nreturn toDomainOrder(providerOrder);\nGood Python:\nreturn to_domain_order(provider_order)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-125: Clean Boundaries. Topic: Boundaries. Rule family: boundaries. Aliases and smell terms: clean boundaries, boundary design, adapter, third party code, integration seam, boundaries, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to clean boundaries: Keep boundary translation in one place. Search terms that should match this issue include clean boundaries, boundary design, adapter, third party code, integration seam. Use when: Use this pattern when planning or reviewing code where keep boundary translation in one place. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: return toDomainOrder(providerOrder); Good Python example: return to_domain_order(provider_order) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "return to_domain_order(provider_order)", "typescript": "return toDomainOrder(providerOrder);"}, "id": "CC-125", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to clean boundaries: Keep boundary translation in one place. Search terms that should match this issue include clean boundaries, boundary design, adapter, third party code, integration seam.", "rule_family": "boundaries", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Clean Boundaries", "topic": "Boundaries", "use_when": "Use this pattern when planning or reviewing code where keep boundary translation in one place. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["three laws of tdd", "three laws", "of tdd", "unit test", "test smell", "test design", "test quality", "unit tests", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-126 Three Laws Of TDD\nTopic: Unit Tests\nAliases: three laws of tdd, three laws, of tdd, unit test, test smell, test design, test quality, unit tests, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to three laws of tdd: Write a failing test before production behavior, then make it pass simply. Search terms that should match this issue include three laws of tdd, three laws, of tdd, unit test, test smell.\nUse when: Use this pattern when planning or reviewing code where write a failing test before production behavior, then make it pass simply. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nexpect(totalFor(emptyCart)).toEqual(money('0.00'));\nGood Python:\nassert total_for(empty_cart) == Money('0.00')\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-126: Three Laws Of TDD. Topic: Unit Tests. Rule family: tests. Aliases and smell terms: three laws of tdd, three laws, of tdd, unit test, test smell, test design, test quality, unit tests, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to three laws of tdd: Write a failing test before production behavior, then make it pass simply. Search terms that should match this issue include three laws of tdd, three laws, of tdd, unit test, test smell. Use when: Use this pattern when planning or reviewing code where write a failing test before production behavior, then make it pass simply. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: expect(totalFor(emptyCart)).toEqual(money('0.00')); Good Python example: assert total_for(empty_cart) == Money('0.00') Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "assert total_for(empty_cart) == Money('0.00')", "typescript": "expect(totalFor(emptyCart)).toEqual(money('0.00'));"}, "id": "CC-126", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to three laws of tdd: Write a failing test before production behavior, then make it pass simply. Search terms that should match this issue include three laws of tdd, three laws, of tdd, unit test, test smell.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Three Laws Of TDD", "topic": "Unit Tests", "use_when": "Use this pattern when planning or reviewing code where write a failing test before production behavior, then make it pass simply. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["keeping tests clean", "keeping tests", "tests clean", "unit test", "test smell", "test design", "test quality", "unit tests", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-127 Keeping Tests Clean\nTopic: Unit Tests\nAliases: keeping tests clean, keeping tests, tests clean, unit test, test smell, test design, test quality, unit tests, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to keeping tests clean: Refactor tests so they remain readable and useful. Search terms that should match this issue include keeping tests clean, keeping tests, tests clean, unit test, test smell.\nUse when: Use this pattern when planning or reviewing code where refactor tests so they remain readable and useful. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nexpect(orderTotal(cartWith('book'))).toEqual(money('12.00'));\nGood Python:\nassert order_total(cart_with('book')) == Money('12.00')\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-127: Keeping Tests Clean. Topic: Unit Tests. Rule family: tests. Aliases and smell terms: keeping tests clean, keeping tests, tests clean, unit test, test smell, test design, test quality, unit tests, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to keeping tests clean: Refactor tests so they remain readable and useful. Search terms that should match this issue include keeping tests clean, keeping tests, tests clean, unit test, test smell. Use when: Use this pattern when planning or reviewing code where refactor tests so they remain readable and useful. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: expect(orderTotal(cartWith('book'))).toEqual(money('12.00')); Good Python example: assert order_total(cart_with('book')) == Money('12.00') Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "assert order_total(cart_with('book')) == Money('12.00')", "typescript": "expect(orderTotal(cartWith('book'))).toEqual(money('12.00'));"}, "id": "CC-127", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to keeping tests clean: Refactor tests so they remain readable and useful. Search terms that should match this issue include keeping tests clean, keeping tests, tests clean, unit test, test smell.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Keeping Tests Clean", "topic": "Unit Tests", "use_when": "Use this pattern when planning or reviewing code where refactor tests so they remain readable and useful. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["tests enable the ilities", "tests enable", "the ilities", "unit test", "test smell", "test design", "test quality", "unit tests", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-128 Tests Enable The Ilities\nTopic: Unit Tests\nAliases: tests enable the ilities, tests enable, the ilities, unit test, test smell, test design, test quality, unit tests, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to tests enable the ilities: Clean tests make refactoring, portability, and maintainability safer. Search terms that should match this issue include tests enable the ilities, tests enable, the ilities, unit test, test smell.\nUse when: Use this pattern when planning or reviewing code where clean tests make refactoring, portability, and maintainability safer. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nawait expectCheckoutToPublishReceipt(cart);\nGood Python:\nexpect_checkout_to_publish_receipt(cart)\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-128: Tests Enable The Ilities. Topic: Unit Tests. Rule family: tests. Aliases and smell terms: tests enable the ilities, tests enable, the ilities, unit test, test smell, test design, test quality, unit tests, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to tests enable the ilities: Clean tests make refactoring, portability, and maintainability safer. Search terms that should match this issue include tests enable the ilities, tests enable, the ilities, unit test, test smell. Use when: Use this pattern when planning or reviewing code where clean tests make refactoring, portability, and maintainability safer. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: await expectCheckoutToPublishReceipt(cart); Good Python example: expect_checkout_to_publish_receipt(cart) Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "expect_checkout_to_publish_receipt(cart)", "typescript": "await expectCheckoutToPublishReceipt(cart);"}, "id": "CC-128", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to tests enable the ilities: Clean tests make refactoring, portability, and maintainability safer. Search terms that should match this issue include tests enable the ilities, tests enable, the ilities, unit test, test smell.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Tests Enable The Ilities", "topic": "Unit Tests", "use_when": "Use this pattern when planning or reviewing code where clean tests make refactoring, portability, and maintainability safer. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["clean tests", "unit test", "test smell", "test design", "test quality", "unit tests", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-129 Clean Tests\nTopic: Unit Tests\nAliases: clean tests, unit test, test smell, test design, test quality, unit tests, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to clean tests: Make test setup, action, and assertion obvious. Search terms that should match this issue include clean tests, unit test, test smell, test design, test quality.\nUse when: Use this pattern when planning or reviewing code where make test setup, action, and assertion obvious. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nconst receipt = await checkout(cart);\nexpect(receipt.total).toEqual(cart.total);\nGood Python:\nreceipt = checkout(cart)\nassert receipt.total == cart.total\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-129: Clean Tests. Topic: Unit Tests. Rule family: tests. Aliases and smell terms: clean tests, unit test, test smell, test design, test quality, unit tests, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to clean tests: Make test setup, action, and assertion obvious. Search terms that should match this issue include clean tests, unit test, test smell, test design, test quality. Use when: Use this pattern when planning or reviewing code where make test setup, action, and assertion obvious. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const receipt = await checkout(cart);\nexpect(receipt.total).toEqual(cart.total); Good Python example: receipt = checkout(cart)\nassert receipt.total == cart.total Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "receipt = checkout(cart)\nassert receipt.total == cart.total", "typescript": "const receipt = await checkout(cart);\nexpect(receipt.total).toEqual(cart.total);"}, "id": "CC-129", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to clean tests: Make test setup, action, and assertion obvious. Search terms that should match this issue include clean tests, unit test, test smell, test design, test quality.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Clean Tests", "topic": "Unit Tests", "use_when": "Use this pattern when planning or reviewing code where make test setup, action, and assertion obvious. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["domain specific testing language", "domain specific", "testing language", "unit test", "test smell", "test design", "test quality", "unit tests", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-130 Domain Specific Testing Language\nTopic: Unit Tests\nAliases: domain specific testing language, domain specific, testing language, unit test, test smell, test design, test quality, unit tests, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to domain specific testing language: Build test helpers that speak the domain. Search terms that should match this issue include domain specific testing language, domain specific, testing language, unit test, test smell.\nUse when: Use this pattern when planning or reviewing code where build test helpers that speak the domain. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nconst cart = cartWithItems(item('book', '12.00'));\nGood Python:\ncart = cart_with_items(item('book', '12.00'))\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-130: Domain Specific Testing Language. Topic: Unit Tests. Rule family: tests. Aliases and smell terms: domain specific testing language, domain specific, testing language, unit test, test smell, test design, test quality, unit tests, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to domain specific testing language: Build test helpers that speak the domain. Search terms that should match this issue include domain specific testing language, domain specific, testing language, unit test, test smell. Use when: Use this pattern when planning or reviewing code where build test helpers that speak the domain. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const cart = cartWithItems(item('book', '12.00')); Good Python example: cart = cart_with_items(item('book', '12.00')) Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "cart = cart_with_items(item('book', '12.00'))", "typescript": "const cart = cartWithItems(item('book', '12.00'));"}, "id": "CC-130", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to domain specific testing language: Build test helpers that speak the domain. Search terms that should match this issue include domain specific testing language, domain specific, testing language, unit test, test smell.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Domain Specific Testing Language", "topic": "Unit Tests", "use_when": "Use this pattern when planning or reviewing code where build test helpers that speak the domain. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["dual standard", "unit test", "test smell", "test design", "test quality", "unit tests", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-131 Dual Standard\nTopic: Unit Tests\nAliases: dual standard, unit test, test smell, test design, test quality, unit tests, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to dual standard: Tests may use concise helpers while production code stays explicit and robust. Search terms that should match this issue include dual standard, unit test, test smell, test design, test quality.\nUse when: Use this pattern when planning or reviewing code where tests may use concise helpers while production code stays explicit and robust. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nexpect(renderedInvoice(invoice)).toContainTotal('12.00');\nGood Python:\nassert rendered_invoice(invoice).contains_total('12.00')\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-131: Dual Standard. Topic: Unit Tests. Rule family: tests. Aliases and smell terms: dual standard, unit test, test smell, test design, test quality, unit tests, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to dual standard: Tests may use concise helpers while production code stays explicit and robust. Search terms that should match this issue include dual standard, unit test, test smell, test design, test quality. Use when: Use this pattern when planning or reviewing code where tests may use concise helpers while production code stays explicit and robust. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: expect(renderedInvoice(invoice)).toContainTotal('12.00'); Good Python example: assert rendered_invoice(invoice).contains_total('12.00') Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "assert rendered_invoice(invoice).contains_total('12.00')", "typescript": "expect(renderedInvoice(invoice)).toContainTotal('12.00');"}, "id": "CC-131", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to dual standard: Tests may use concise helpers while production code stays explicit and robust. Search terms that should match this issue include dual standard, unit test, test smell, test design, test quality.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Dual Standard", "topic": "Unit Tests", "use_when": "Use this pattern when planning or reviewing code where tests may use concise helpers while production code stays explicit and robust. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["one assert per test", "one assert", "per test", "unit test", "test smell", "test design", "test quality", "unit tests", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-132 One Assert Per Test\nTopic: Unit Tests\nAliases: one assert per test, one assert, per test, unit test, test smell, test design, test quality, unit tests, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to one assert per test: Prefer tests that fail for one clear behavioral reason. Search terms that should match this issue include one assert per test, one assert, per test, unit test, test smell.\nUse when: Use this pattern when planning or reviewing code where prefer tests that fail for one clear behavioral reason. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nexpect(validatePassword('short')).toThrow(WeakPasswordError);\nGood Python:\nwith pytest.raises(WeakPasswordError):\n    validate_password('short')\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-132: One Assert Per Test. Topic: Unit Tests. Rule family: tests. Aliases and smell terms: one assert per test, one assert, per test, unit test, test smell, test design, test quality, unit tests, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to one assert per test: Prefer tests that fail for one clear behavioral reason. Search terms that should match this issue include one assert per test, one assert, per test, unit test, test smell. Use when: Use this pattern when planning or reviewing code where prefer tests that fail for one clear behavioral reason. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: expect(validatePassword('short')).toThrow(WeakPasswordError); Good Python example: with pytest.raises(WeakPasswordError):\n    validate_password('short') Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "with pytest.raises(WeakPasswordError):\n    validate_password('short')", "typescript": "expect(validatePassword('short')).toThrow(WeakPasswordError);"}, "id": "CC-132", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to one assert per test: Prefer tests that fail for one clear behavioral reason. Search terms that should match this issue include one assert per test, one assert, per test, unit test, test smell.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "One Assert Per Test", "topic": "Unit Tests", "use_when": "Use this pattern when planning or reviewing code where prefer tests that fail for one clear behavioral reason. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["single concept per test", "single concept", "per test", "unit test", "test smell", "test design", "test quality", "unit tests", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-133 Single Concept Per Test\nTopic: Unit Tests\nAliases: single concept per test, single concept, per test, unit test, test smell, test design, test quality, unit tests, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to single concept per test: Split unrelated examples into separate tests. Search terms that should match this issue include single concept per test, single concept, per test, unit test, test smell.\nUse when: Use this pattern when planning or reviewing code where split unrelated examples into separate tests. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nit('rejects blank email', () => expectSignup({ email: '' }).toFail());\nGood Python:\ndef test_rejects_blank_email():\n    assert_signup({'email': ''}).fails()\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-133: Single Concept Per Test. Topic: Unit Tests. Rule family: tests. Aliases and smell terms: single concept per test, single concept, per test, unit test, test smell, test design, test quality, unit tests, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to single concept per test: Split unrelated examples into separate tests. Search terms that should match this issue include single concept per test, single concept, per test, unit test, test smell. Use when: Use this pattern when planning or reviewing code where split unrelated examples into separate tests. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: it('rejects blank email', () => expectSignup({ email: '' }).toFail()); Good Python example: def test_rejects_blank_email():\n    assert_signup({'email': ''}).fails() Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "def test_rejects_blank_email():\n    assert_signup({'email': ''}).fails()", "typescript": "it('rejects blank email', () => expectSignup({ email: '' }).toFail());"}, "id": "CC-133", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to single concept per test: Split unrelated examples into separate tests. Search terms that should match this issue include single concept per test, single concept, per test, unit test, test smell.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Single Concept Per Test", "topic": "Unit Tests", "use_when": "Use this pattern when planning or reviewing code where split unrelated examples into separate tests. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["first tests", "unit test", "test smell", "test design", "test quality", "unit tests", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-134 FIRST Tests\nTopic: Unit Tests\nAliases: first tests, unit test, test smell, test design, test quality, unit tests, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to first tests: Keep tests fast, independent, repeatable, self-validating, and timely. Search terms that should match this issue include first tests, unit test, test smell, test design, test quality.\nUse when: Use this pattern when planning or reviewing code where keep tests fast, independent, repeatable, self-validating, and timely. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nexpect(calculateTax(order)).toEqual(money('0.83'));\nGood Python:\nassert calculate_tax(order) == Money('0.83')\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-134: FIRST Tests. Topic: Unit Tests. Rule family: tests. Aliases and smell terms: first tests, unit test, test smell, test design, test quality, unit tests, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to first tests: Keep tests fast, independent, repeatable, self-validating, and timely. Search terms that should match this issue include first tests, unit test, test smell, test design, test quality. Use when: Use this pattern when planning or reviewing code where keep tests fast, independent, repeatable, self-validating, and timely. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: expect(calculateTax(order)).toEqual(money('0.83')); Good Python example: assert calculate_tax(order) == Money('0.83') Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "assert calculate_tax(order) == Money('0.83')", "typescript": "expect(calculateTax(order)).toEqual(money('0.83'));"}, "id": "CC-134", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to first tests: Keep tests fast, independent, repeatable, self-validating, and timely. Search terms that should match this issue include first tests, unit test, test smell, test design, test quality.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "FIRST Tests", "topic": "Unit Tests", "use_when": "Use this pattern when planning or reviewing code where keep tests fast, independent, repeatable, self-validating, and timely. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["class organization", "class smell", "cohesion", "single responsibility", "class design", "classes", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-135 Class Organization\nTopic: Classes\nAliases: class organization, class smell, cohesion, single responsibility, class design, classes, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to class organization: Order class members so readers see constants, state, public API, then private details. Search terms that should match this issue include class organization, class smell, cohesion, single responsibility, class design.\nUse when: Use this pattern when planning or reviewing code where order class members so readers see constants, state, public API, then private details. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nclass Invoice {\n  total(): Money { return this.subtotal.plus(this.tax); }\n}\nGood Python:\nclass Invoice:\n    def total(self) -> Money:\n        return self.subtotal + self.tax\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-135: Class Organization. Topic: Classes. Rule family: classes. Aliases and smell terms: class organization, class smell, cohesion, single responsibility, class design, classes, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to class organization: Order class members so readers see constants, state, public API, then private details. Search terms that should match this issue include class organization, class smell, cohesion, single responsibility, class design. Use when: Use this pattern when planning or reviewing code where order class members so readers see constants, state, public API, then private details. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: class Invoice {\n  total(): Money { return this.subtotal.plus(this.tax); }\n} Good Python example: class Invoice:\n    def total(self) -> Money:\n        return self.subtotal + self.tax Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "class Invoice:\n    def total(self) -> Money:\n        return self.subtotal + self.tax", "typescript": "class Invoice {\n  total(): Money { return this.subtotal.plus(this.tax); }\n}"}, "id": "CC-135", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to class organization: Order class members so readers see constants, state, public API, then private details. Search terms that should match this issue include class organization, class smell, cohesion, single responsibility, class design.", "rule_family": "classes", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Class Organization", "topic": "Classes", "use_when": "Use this pattern when planning or reviewing code where order class members so readers see constants, state, public API, then private details. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["encapsulation", "class smell", "cohesion", "single responsibility", "class design", "classes", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-136 Encapsulation\nTopic: Classes\nAliases: encapsulation, class smell, cohesion, single responsibility, class design, classes, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to encapsulation: Keep state private unless exposing it improves the design. Search terms that should match this issue include encapsulation, class smell, cohesion, single responsibility, class design.\nUse when: Use this pattern when planning or reviewing code where keep state private unless exposing it improves the design. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nclass Counter {\n  private value = 0;\n  increment(): number { return ++this.value; }\n}\nGood Python:\nclass Counter:\n    def __init__(self) -> None:\n        self._value = 0\n    def increment(self) -> int:\n        self._value += 1\n        return self._value\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-136: Encapsulation. Topic: Classes. Rule family: classes. Aliases and smell terms: encapsulation, class smell, cohesion, single responsibility, class design, classes, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to encapsulation: Keep state private unless exposing it improves the design. Search terms that should match this issue include encapsulation, class smell, cohesion, single responsibility, class design. Use when: Use this pattern when planning or reviewing code where keep state private unless exposing it improves the design. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: class Counter {\n  private value = 0;\n  increment(): number { return ++this.value; }\n} Good Python example: class Counter:\n    def __init__(self) -> None:\n        self._value = 0\n    def increment(self) -> int:\n        self._value += 1\n        return self._value Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "class Counter:\n    def __init__(self) -> None:\n        self._value = 0\n    def increment(self) -> int:\n        self._value += 1\n        return self._value", "typescript": "class Counter {\n  private value = 0;\n  increment(): number { return ++this.value; }\n}"}, "id": "CC-136", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to encapsulation: Keep state private unless exposing it improves the design. Search terms that should match this issue include encapsulation, class smell, cohesion, single responsibility, class design.", "rule_family": "classes", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Encapsulation", "topic": "Classes", "use_when": "Use this pattern when planning or reviewing code where keep state private unless exposing it improves the design. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["classes should be small", "classes should", "be small", "class smell", "cohesion", "single responsibility", "class design", "classes", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-137 Classes Should Be Small\nTopic: Classes\nAliases: classes should be small, classes should, be small, class smell, cohesion, single responsibility, class design, classes, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to classes should be small: A class should represent one narrow concept. Search terms that should match this issue include classes should be small, classes should, be small, class smell, cohesion.\nUse when: Use this pattern when planning or reviewing code where a class should represent one narrow concept. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nclass PasswordPolicy { accepts(password: string): boolean { return password.length >= 12; } }\nGood Python:\nclass PasswordPolicy:\n    def accepts(self, password: str) -> bool:\n        return len(password) >= 12\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-137: Classes Should Be Small. Topic: Classes. Rule family: classes. Aliases and smell terms: classes should be small, classes should, be small, class smell, cohesion, single responsibility, class design, classes, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to classes should be small: A class should represent one narrow concept. Search terms that should match this issue include classes should be small, classes should, be small, class smell, cohesion. Use when: Use this pattern when planning or reviewing code where a class should represent one narrow concept. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: class PasswordPolicy { accepts(password: string): boolean { return password.length >= 12; } } Good Python example: class PasswordPolicy:\n    def accepts(self, password: str) -> bool:\n        return len(password) >= 12 Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "class PasswordPolicy:\n    def accepts(self, password: str) -> bool:\n        return len(password) >= 12", "typescript": "class PasswordPolicy { accepts(password: string): boolean { return password.length >= 12; } }"}, "id": "CC-137", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to classes should be small: A class should represent one narrow concept. Search terms that should match this issue include classes should be small, classes should, be small, class smell, cohesion.", "rule_family": "classes", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Classes Should Be Small", "topic": "Classes", "use_when": "Use this pattern when planning or reviewing code where a class should represent one narrow concept. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["single responsibility principle", "single responsibility", "responsibility principle", "class smell", "cohesion", "class design", "classes", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "def submit_order(payload):\n    validate(payload)\n    db.save(payload)\n    email(payload)", "typescript": "async function submitOrder(input) { validate(input); await db.save(input); await email(input); }"}, "display_text": "CC-138 Single Responsibility Principle\nTopic: Classes\nAliases: single responsibility principle, single responsibility, responsibility principle, class smell, cohesion, class design, classes, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to single responsibility principle: Give a class one reason to change. Search terms that should match this issue include single responsibility principle, single responsibility, responsibility principle, class smell, cohesion.\nUse when: Use this pattern when planning or reviewing code where give a class one reason to change. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nclass InvoicePrinter { print(invoice: Invoice): Pdf { return renderInvoice(invoice); } }\nGood Python:\nclass InvoicePrinter:\n    def print(self, invoice: Invoice) -> Pdf:\n        return render_invoice(invoice)\nBad TypeScript:\nasync function submitOrder(input) { validate(input); await db.save(input); await email(input); }\nBad Python:\ndef submit_order(payload):\n    validate(payload)\n    db.save(payload)\n    email(payload)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-138: Single Responsibility Principle. Topic: Classes. Rule family: classes. Aliases and smell terms: single responsibility principle, single responsibility, responsibility principle, class smell, cohesion, class design, classes, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to single responsibility principle: Give a class one reason to change. Search terms that should match this issue include single responsibility principle, single responsibility, responsibility principle, class smell, cohesion. Use when: Use this pattern when planning or reviewing code where give a class one reason to change. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: class InvoicePrinter { print(invoice: Invoice): Pdf { return renderInvoice(invoice); } } Good Python example: class InvoicePrinter:\n    def print(self, invoice: Invoice) -> Pdf:\n        return render_invoice(invoice) Bad TypeScript example: async function submitOrder(input) { validate(input); await db.save(input); await email(input); } Bad Python example: def submit_order(payload):\n    validate(payload)\n    db.save(payload)\n    email(payload)", "good_examples": {"python": "class InvoicePrinter:\n    def print(self, invoice: Invoice) -> Pdf:\n        return render_invoice(invoice)", "typescript": "class InvoicePrinter { print(invoice: Invoice): Pdf { return renderInvoice(invoice); } }"}, "id": "CC-138", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to single responsibility principle: Give a class one reason to change. Search terms that should match this issue include single responsibility principle, single responsibility, responsibility principle, class smell, cohesion.", "rule_family": "classes", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Single Responsibility Principle", "topic": "Classes", "use_when": "Use this pattern when planning or reviewing code where give a class one reason to change. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["cohesion", "class smell", "single responsibility", "class design", "classes", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-139 Cohesion\nTopic: Classes\nAliases: cohesion, class smell, single responsibility, class design, classes, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to cohesion: Methods should share the same core state and purpose. Search terms that should match this issue include cohesion, class smell, single responsibility, class design, classes.\nUse when: Use this pattern when planning or reviewing code where methods should share the same core state and purpose. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nclass RetryPolicy { constructor(private max: number) {} shouldRetry(n: number) { return n < this.max; } }\nGood Python:\n@dataclass\nclass RetryPolicy:\n    max_attempts: int\n    def should_retry(self, attempt: int) -> bool:\n        return attempt < self.max_attempts\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-139: Cohesion. Topic: Classes. Rule family: classes. Aliases and smell terms: cohesion, class smell, single responsibility, class design, classes, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to cohesion: Methods should share the same core state and purpose. Search terms that should match this issue include cohesion, class smell, single responsibility, class design, classes. Use when: Use this pattern when planning or reviewing code where methods should share the same core state and purpose. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: class RetryPolicy { constructor(private max: number) {} shouldRetry(n: number) { return n < this.max; } } Good Python example: @dataclass\nclass RetryPolicy:\n    max_attempts: int\n    def should_retry(self, attempt: int) -> bool:\n        return attempt < self.max_attempts Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "@dataclass\nclass RetryPolicy:\n    max_attempts: int\n    def should_retry(self, attempt: int) -> bool:\n        return attempt < self.max_attempts", "typescript": "class RetryPolicy { constructor(private max: number) {} shouldRetry(n: number) { return n < this.max; } }"}, "id": "CC-139", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to cohesion: Methods should share the same core state and purpose. Search terms that should match this issue include cohesion, class smell, single responsibility, class design, classes.", "rule_family": "classes", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Cohesion", "topic": "Classes", "use_when": "Use this pattern when planning or reviewing code where methods should share the same core state and purpose. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["many small classes", "many small", "small classes", "class smell", "cohesion", "single responsibility", "class design", "classes", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-140 Many Small Classes\nTopic: Classes\nAliases: many small classes, many small, small classes, class smell, cohesion, single responsibility, class design, classes, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to many small classes: Split responsibilities when cohesion drops. Search terms that should match this issue include many small classes, many small, small classes, class smell, cohesion.\nUse when: Use this pattern when planning or reviewing code where split responsibilities when cohesion drops. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst tax = taxCalculator.calculate(order);\nGood Python:\ntax = tax_calculator.calculate(order)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-140: Many Small Classes. Topic: Classes. Rule family: classes. Aliases and smell terms: many small classes, many small, small classes, class smell, cohesion, single responsibility, class design, classes, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to many small classes: Split responsibilities when cohesion drops. Search terms that should match this issue include many small classes, many small, small classes, class smell, cohesion. Use when: Use this pattern when planning or reviewing code where split responsibilities when cohesion drops. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const tax = taxCalculator.calculate(order); Good Python example: tax = tax_calculator.calculate(order) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "tax = tax_calculator.calculate(order)", "typescript": "const tax = taxCalculator.calculate(order);"}, "id": "CC-140", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to many small classes: Split responsibilities when cohesion drops. Search terms that should match this issue include many small classes, many small, small classes, class smell, cohesion.", "rule_family": "classes", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Many Small Classes", "topic": "Classes", "use_when": "Use this pattern when planning or reviewing code where split responsibilities when cohesion drops. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["organizing for change", "organizing for", "for change", "class smell", "cohesion", "single responsibility", "class design", "classes", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-141 Organizing For Change\nTopic: Classes\nAliases: organizing for change, organizing for, for change, class smell, cohesion, single responsibility, class design, classes, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to organizing for change: Place volatile policy behind interfaces or small modules. Search terms that should match this issue include organizing for change, organizing for, for change, class smell, cohesion.\nUse when: Use this pattern when planning or reviewing code where place volatile policy behind interfaces or small modules. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\npricingPolicy.price(order);\nGood Python:\npricing_policy.price(order)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-141: Organizing For Change. Topic: Classes. Rule family: classes. Aliases and smell terms: organizing for change, organizing for, for change, class smell, cohesion, single responsibility, class design, classes, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to organizing for change: Place volatile policy behind interfaces or small modules. Search terms that should match this issue include organizing for change, organizing for, for change, class smell, cohesion. Use when: Use this pattern when planning or reviewing code where place volatile policy behind interfaces or small modules. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: pricingPolicy.price(order); Good Python example: pricing_policy.price(order) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "pricing_policy.price(order)", "typescript": "pricingPolicy.price(order);"}, "id": "CC-141", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to organizing for change: Place volatile policy behind interfaces or small modules. Search terms that should match this issue include organizing for change, organizing for, for change, class smell, cohesion.", "rule_family": "classes", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Organizing For Change", "topic": "Classes", "use_when": "Use this pattern when planning or reviewing code where place volatile policy behind interfaces or small modules. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["isolating from change", "isolating from", "from change", "class smell", "cohesion", "single responsibility", "class design", "classes", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-142 Isolating From Change\nTopic: Classes\nAliases: isolating from change, isolating from, from change, class smell, cohesion, single responsibility, class design, classes, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to isolating from change: Depend on stable abstractions at change-prone boundaries. Search terms that should match this issue include isolating from change, isolating from, from change, class smell, cohesion.\nUse when: Use this pattern when planning or reviewing code where depend on stable abstractions at change-prone boundaries. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconstructor(private readonly rates: ExchangeRateProvider) {}\nGood Python:\ndef __init__(self, rates: ExchangeRateProvider) -> None:\n    self._rates = rates\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-142: Isolating From Change. Topic: Classes. Rule family: classes. Aliases and smell terms: isolating from change, isolating from, from change, class smell, cohesion, single responsibility, class design, classes, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to isolating from change: Depend on stable abstractions at change-prone boundaries. Search terms that should match this issue include isolating from change, isolating from, from change, class smell, cohesion. Use when: Use this pattern when planning or reviewing code where depend on stable abstractions at change-prone boundaries. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: constructor(private readonly rates: ExchangeRateProvider) {} Good Python example: def __init__(self, rates: ExchangeRateProvider) -> None:\n    self._rates = rates Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def __init__(self, rates: ExchangeRateProvider) -> None:\n    self._rates = rates", "typescript": "constructor(private readonly rates: ExchangeRateProvider) {}"}, "id": "CC-142", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to isolating from change: Depend on stable abstractions at change-prone boundaries. Search terms that should match this issue include isolating from change, isolating from, from change, class smell, cohesion.", "rule_family": "classes", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Isolating From Change", "topic": "Classes", "use_when": "Use this pattern when planning or reviewing code where depend on stable abstractions at change-prone boundaries. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["build a city", "build a", "a city", "system design", "dependency injection", "composition root", "architecture", "systems", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-143 Build A City\nTopic: Systems\nAliases: build a city, build a, a city, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to build a city: Separate high-level system assembly from local component behavior. Search terms that should match this issue include build a city, build a, a city, system design, dependency injection.\nUse when: Use this pattern when planning or reviewing code where separate high-level system assembly from local component behavior. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst app = createApp(container.resolve(OrderService));\nGood Python:\napp = create_app(container.resolve(OrderService))\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: review_only", "embedding_text": "Clean code pattern CC-143: Build A City. Topic: Systems. Rule family: systems. Aliases and smell terms: build a city, build a, a city, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to build a city: Separate high-level system assembly from local component behavior. Search terms that should match this issue include build a city, build a, a city, system design, dependency injection. Use when: Use this pattern when planning or reviewing code where separate high-level system assembly from local component behavior. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const app = createApp(container.resolve(OrderService)); Good Python example: app = create_app(container.resolve(OrderService)) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "app = create_app(container.resolve(OrderService))", "typescript": "const app = createApp(container.resolve(OrderService));"}, "id": "CC-143", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "review_only", "problem": "Code has a clean-code risk related to build a city: Separate high-level system assembly from local component behavior. Search terms that should match this issue include build a city, build a, a city, system design, dependency injection.", "rule_family": "systems", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Build A City", "topic": "Systems", "use_when": "Use this pattern when planning or reviewing code where separate high-level system assembly from local component behavior. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["separate construction from use", "separate construction", "from use", "system design", "dependency injection", "composition root", "architecture", "systems", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-144 Separate Construction From Use\nTopic: Systems\nAliases: separate construction from use, separate construction, from use, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to separate construction from use: Construct dependencies at composition roots, not inside business logic. Search terms that should match this issue include separate construction from use, separate construction, from use, system design, dependency injection.\nUse when: Use this pattern when planning or reviewing code where construct dependencies at composition roots, not inside business logic. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst service = new OrderService(repository, gateway);\nGood Python:\nservice = OrderService(repository, gateway)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-144: Separate Construction From Use. Topic: Systems. Rule family: systems. Aliases and smell terms: separate construction from use, separate construction, from use, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to separate construction from use: Construct dependencies at composition roots, not inside business logic. Search terms that should match this issue include separate construction from use, separate construction, from use, system design, dependency injection. Use when: Use this pattern when planning or reviewing code where construct dependencies at composition roots, not inside business logic. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const service = new OrderService(repository, gateway); Good Python example: service = OrderService(repository, gateway) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "service = OrderService(repository, gateway)", "typescript": "const service = new OrderService(repository, gateway);"}, "id": "CC-144", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to separate construction from use: Construct dependencies at composition roots, not inside business logic. Search terms that should match this issue include separate construction from use, separate construction, from use, system design, dependency injection.", "rule_family": "systems", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Separate Construction From Use", "topic": "Systems", "use_when": "Use this pattern when planning or reviewing code where construct dependencies at composition roots, not inside business logic. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["separation of main", "separation of", "of main", "system design", "dependency injection", "composition root", "architecture", "systems", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-145 Separation Of Main\nTopic: Systems\nAliases: separation of main, separation of, of main, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to separation of main: Keep main responsible for wiring, leaving behavior to application services. Search terms that should match this issue include separation of main, separation of, of main, system design, dependency injection.\nUse when: Use this pattern when planning or reviewing code where keep main responsible for wiring, leaving behavior to application services. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nmain().catch(reportStartupError);\nGood Python:\nif __name__ == '__main__':\n    main()\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-145: Separation Of Main. Topic: Systems. Rule family: systems. Aliases and smell terms: separation of main, separation of, of main, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to separation of main: Keep main responsible for wiring, leaving behavior to application services. Search terms that should match this issue include separation of main, separation of, of main, system design, dependency injection. Use when: Use this pattern when planning or reviewing code where keep main responsible for wiring, leaving behavior to application services. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: main().catch(reportStartupError); Good Python example: if __name__ == '__main__':\n    main() Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "if __name__ == '__main__':\n    main()", "typescript": "main().catch(reportStartupError);"}, "id": "CC-145", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to separation of main: Keep main responsible for wiring, leaving behavior to application services. Search terms that should match this issue include separation of main, separation of, of main, system design, dependency injection.", "rule_family": "systems", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Separation Of Main", "topic": "Systems", "use_when": "Use this pattern when planning or reviewing code where keep main responsible for wiring, leaving behavior to application services. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["factories", "system design", "dependency injection", "composition root", "architecture", "systems", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-146 Factories\nTopic: Systems\nAliases: factories, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to factories: Use factories when creation is complex or policy-driven. Search terms that should match this issue include factories, system design, dependency injection, composition root, architecture.\nUse when: Use this pattern when planning or reviewing code where use factories when creation is complex or policy-driven. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst gateway = paymentGatewayFactory.forRegion(region);\nGood Python:\ngateway = payment_gateway_factory.for_region(region)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-146: Factories. Topic: Systems. Rule family: systems. Aliases and smell terms: factories, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to factories: Use factories when creation is complex or policy-driven. Search terms that should match this issue include factories, system design, dependency injection, composition root, architecture. Use when: Use this pattern when planning or reviewing code where use factories when creation is complex or policy-driven. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const gateway = paymentGatewayFactory.forRegion(region); Good Python example: gateway = payment_gateway_factory.for_region(region) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "gateway = payment_gateway_factory.for_region(region)", "typescript": "const gateway = paymentGatewayFactory.forRegion(region);"}, "id": "CC-146", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to factories: Use factories when creation is complex or policy-driven. Search terms that should match this issue include factories, system design, dependency injection, composition root, architecture.", "rule_family": "systems", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Factories", "topic": "Systems", "use_when": "Use this pattern when planning or reviewing code where use factories when creation is complex or policy-driven. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["dependency injection", "system design", "composition root", "architecture", "systems", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-147 Dependency Injection\nTopic: Systems\nAliases: dependency injection, system design, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to dependency injection: Pass dependencies in so modules are testable and replaceable. Search terms that should match this issue include dependency injection, system design, composition root, architecture, systems.\nUse when: Use this pattern when planning or reviewing code where pass dependencies in so modules are testable and replaceable. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nnew CheckoutService(paymentGateway, orderRepository);\nGood Python:\nCheckoutService(payment_gateway, order_repository)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-147: Dependency Injection. Topic: Systems. Rule family: systems. Aliases and smell terms: dependency injection, system design, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to dependency injection: Pass dependencies in so modules are testable and replaceable. Search terms that should match this issue include dependency injection, system design, composition root, architecture, systems. Use when: Use this pattern when planning or reviewing code where pass dependencies in so modules are testable and replaceable. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: new CheckoutService(paymentGateway, orderRepository); Good Python example: CheckoutService(payment_gateway, order_repository) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "CheckoutService(payment_gateway, order_repository)", "typescript": "new CheckoutService(paymentGateway, orderRepository);"}, "id": "CC-147", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to dependency injection: Pass dependencies in so modules are testable and replaceable. Search terms that should match this issue include dependency injection, system design, composition root, architecture, systems.", "rule_family": "systems", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Dependency Injection", "topic": "Systems", "use_when": "Use this pattern when planning or reviewing code where pass dependencies in so modules are testable and replaceable. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["scaling up", "system design", "dependency injection", "composition root", "architecture", "systems", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-148 Scaling Up\nTopic: Systems\nAliases: scaling up, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to scaling up: Keep architecture evolvable by separating concerns before size demands it. Search terms that should match this issue include scaling up, system design, dependency injection, composition root, architecture.\nUse when: Use this pattern when planning or reviewing code where keep architecture evolvable by separating concerns before size demands it. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\norderModule.register(container);\nGood Python:\norder_module.register(container)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-148: Scaling Up. Topic: Systems. Rule family: systems. Aliases and smell terms: scaling up, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to scaling up: Keep architecture evolvable by separating concerns before size demands it. Search terms that should match this issue include scaling up, system design, dependency injection, composition root, architecture. Use when: Use this pattern when planning or reviewing code where keep architecture evolvable by separating concerns before size demands it. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: orderModule.register(container); Good Python example: order_module.register(container) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "order_module.register(container)", "typescript": "orderModule.register(container);"}, "id": "CC-148", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to scaling up: Keep architecture evolvable by separating concerns before size demands it. Search terms that should match this issue include scaling up, system design, dependency injection, composition root, architecture.", "rule_family": "systems", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Scaling Up", "topic": "Systems", "use_when": "Use this pattern when planning or reviewing code where keep architecture evolvable by separating concerns before size demands it. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["cross-cutting concerns", "cross cutting concerns", "cross cutting", "cutting concerns", "system design", "dependency injection", "composition root", "architecture", "systems", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-149 Cross-Cutting Concerns\nTopic: Systems\nAliases: cross-cutting concerns, cross cutting concerns, cross cutting, cutting concerns, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to cross-cutting concerns: Apply logging, metrics, and transactions outside core domain logic. Search terms that should match this issue include cross-cutting concerns, cross cutting concerns, cross cutting, cutting concerns, system design.\nUse when: Use this pattern when planning or reviewing code where apply logging, metrics, and transactions outside core domain logic. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nwithMetrics('checkout', () => checkout(order));\nGood Python:\nwith_metrics('checkout', lambda: checkout(order))\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-149: Cross-Cutting Concerns. Topic: Systems. Rule family: systems. Aliases and smell terms: cross-cutting concerns, cross cutting concerns, cross cutting, cutting concerns, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to cross-cutting concerns: Apply logging, metrics, and transactions outside core domain logic. Search terms that should match this issue include cross-cutting concerns, cross cutting concerns, cross cutting, cutting concerns, system design. Use when: Use this pattern when planning or reviewing code where apply logging, metrics, and transactions outside core domain logic. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: withMetrics('checkout', () => checkout(order)); Good Python example: with_metrics('checkout', lambda: checkout(order)) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "with_metrics('checkout', lambda: checkout(order))", "typescript": "withMetrics('checkout', () => checkout(order));"}, "id": "CC-149", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to cross-cutting concerns: Apply logging, metrics, and transactions outside core domain logic. Search terms that should match this issue include cross-cutting concerns, cross cutting concerns, cross cutting, cutting concerns, system design.", "rule_family": "systems", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Cross-Cutting Concerns", "topic": "Systems", "use_when": "Use this pattern when planning or reviewing code where apply logging, metrics, and transactions outside core domain logic. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["java proxies", "system design", "dependency injection", "composition root", "architecture", "systems", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-150 Java Proxies\nTopic: Systems\nAliases: java proxies, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to java proxies: Use proxy-like wrappers for narrow infrastructure concerns. Search terms that should match this issue include java proxies, system design, dependency injection, composition root, architecture.\nUse when: Use this pattern when planning or reviewing code where use proxy-like wrappers for narrow infrastructure concerns. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst repository = withTracing(new SqlOrderRepository(db));\nGood Python:\nrepository = with_tracing(SqlOrderRepository(db))\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-150: Java Proxies. Topic: Systems. Rule family: systems. Aliases and smell terms: java proxies, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to java proxies: Use proxy-like wrappers for narrow infrastructure concerns. Search terms that should match this issue include java proxies, system design, dependency injection, composition root, architecture. Use when: Use this pattern when planning or reviewing code where use proxy-like wrappers for narrow infrastructure concerns. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const repository = withTracing(new SqlOrderRepository(db)); Good Python example: repository = with_tracing(SqlOrderRepository(db)) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "repository = with_tracing(SqlOrderRepository(db))", "typescript": "const repository = withTracing(new SqlOrderRepository(db));"}, "id": "CC-150", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to java proxies: Use proxy-like wrappers for narrow infrastructure concerns. Search terms that should match this issue include java proxies, system design, dependency injection, composition root, architecture.", "rule_family": "systems", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Java Proxies", "topic": "Systems", "use_when": "Use this pattern when planning or reviewing code where use proxy-like wrappers for narrow infrastructure concerns. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["pure java aop frameworks", "pure java", "aop frameworks", "system design", "dependency injection", "composition root", "architecture", "systems", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-151 Pure Java AOP Frameworks\nTopic: Systems\nAliases: pure java aop frameworks, pure java, aop frameworks, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to pure java aop frameworks: Keep domain objects independent from framework aspect plumbing. Search terms that should match this issue include pure java aop frameworks, pure java, aop frameworks, system design, dependency injection.\nUse when: Use this pattern when planning or reviewing code where keep domain objects independent from framework aspect plumbing. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nbankAccount.withdraw(amount);\nGood Python:\nbank_account.withdraw(amount)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-151: Pure Java AOP Frameworks. Topic: Systems. Rule family: systems. Aliases and smell terms: pure java aop frameworks, pure java, aop frameworks, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to pure java aop frameworks: Keep domain objects independent from framework aspect plumbing. Search terms that should match this issue include pure java aop frameworks, pure java, aop frameworks, system design, dependency injection. Use when: Use this pattern when planning or reviewing code where keep domain objects independent from framework aspect plumbing. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: bankAccount.withdraw(amount); Good Python example: bank_account.withdraw(amount) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "bank_account.withdraw(amount)", "typescript": "bankAccount.withdraw(amount);"}, "id": "CC-151", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to pure java aop frameworks: Keep domain objects independent from framework aspect plumbing. Search terms that should match this issue include pure java aop frameworks, pure java, aop frameworks, system design, dependency injection.", "rule_family": "systems", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Pure Java AOP Frameworks", "topic": "Systems", "use_when": "Use this pattern when planning or reviewing code where keep domain objects independent from framework aspect plumbing. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["aspectj aspects", "system design", "dependency injection", "composition root", "architecture", "systems", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-152 AspectJ Aspects\nTopic: Systems\nAliases: aspectj aspects, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to aspectj aspects: Modularize cross-cutting concerns without leaking them into domain code. Search terms that should match this issue include aspectj aspects, system design, dependency injection, composition root, architecture.\nUse when: Use this pattern when planning or reviewing code where modularize cross-cutting concerns without leaking them into domain code. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\n@Transactional()\nasync function transfer(request: TransferRequest) { return transferFunds(request); }\nGood Python:\n@transactional\ndef transfer(request: TransferRequest) -> Receipt:\n    return transfer_funds(request)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-152: AspectJ Aspects. Topic: Systems. Rule family: systems. Aliases and smell terms: aspectj aspects, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to aspectj aspects: Modularize cross-cutting concerns without leaking them into domain code. Search terms that should match this issue include aspectj aspects, system design, dependency injection, composition root, architecture. Use when: Use this pattern when planning or reviewing code where modularize cross-cutting concerns without leaking them into domain code. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: @Transactional()\nasync function transfer(request: TransferRequest) { return transferFunds(request); } Good Python example: @transactional\ndef transfer(request: TransferRequest) -> Receipt:\n    return transfer_funds(request) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "@transactional\ndef transfer(request: TransferRequest) -> Receipt:\n    return transfer_funds(request)", "typescript": "@Transactional()\nasync function transfer(request: TransferRequest) { return transferFunds(request); }"}, "id": "CC-152", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to aspectj aspects: Modularize cross-cutting concerns without leaking them into domain code. Search terms that should match this issue include aspectj aspects, system design, dependency injection, composition root, architecture.", "rule_family": "systems", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "AspectJ Aspects", "topic": "Systems", "use_when": "Use this pattern when planning or reviewing code where modularize cross-cutting concerns without leaking them into domain code. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["test drive system architecture", "test drive", "system architecture", "unit test", "test smell", "test design", "test quality", "systems", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-153 Test Drive System Architecture\nTopic: Systems\nAliases: test drive system architecture, test drive, system architecture, unit test, test smell, test design, test quality, systems, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to test drive system architecture: Let tests pressure architecture through executable use cases. Search terms that should match this issue include test drive system architecture, test drive, system architecture, unit test, test smell.\nUse when: Use this pattern when planning or reviewing code where let tests pressure architecture through executable use cases. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nawait expectCheckoutFlow().toPublishReceipt();\nGood Python:\nexpect_checkout_flow().to_publish_receipt()\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-153: Test Drive System Architecture. Topic: Systems. Rule family: tests. Aliases and smell terms: test drive system architecture, test drive, system architecture, unit test, test smell, test design, test quality, systems, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to test drive system architecture: Let tests pressure architecture through executable use cases. Search terms that should match this issue include test drive system architecture, test drive, system architecture, unit test, test smell. Use when: Use this pattern when planning or reviewing code where let tests pressure architecture through executable use cases. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: await expectCheckoutFlow().toPublishReceipt(); Good Python example: expect_checkout_flow().to_publish_receipt() Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "expect_checkout_flow().to_publish_receipt()", "typescript": "await expectCheckoutFlow().toPublishReceipt();"}, "id": "CC-153", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to test drive system architecture: Let tests pressure architecture through executable use cases. Search terms that should match this issue include test drive system architecture, test drive, system architecture, unit test, test smell.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Test Drive System Architecture", "topic": "Systems", "use_when": "Use this pattern when planning or reviewing code where let tests pressure architecture through executable use cases. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["optimize decision making", "optimize decision", "decision making", "system design", "dependency injection", "composition root", "architecture", "systems", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-154 Optimize Decision Making\nTopic: Systems\nAliases: optimize decision making, optimize decision, decision making, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to optimize decision making: Delay decisions until the code has enough information, while keeping options isolated. Search terms that should match this issue include optimize decision making, optimize decision, decision making, system design, dependency injection.\nUse when: Use this pattern when planning or reviewing code where delay decisions until the code has enough information, while keeping options isolated. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst store = featureFlags.useRedis ? redisStore : memoryStore;\nGood Python:\nstore = redis_store if feature_flags.use_redis else memory_store\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-154: Optimize Decision Making. Topic: Systems. Rule family: systems. Aliases and smell terms: optimize decision making, optimize decision, decision making, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to optimize decision making: Delay decisions until the code has enough information, while keeping options isolated. Search terms that should match this issue include optimize decision making, optimize decision, decision making, system design, dependency injection. Use when: Use this pattern when planning or reviewing code where delay decisions until the code has enough information, while keeping options isolated. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const store = featureFlags.useRedis ? redisStore : memoryStore; Good Python example: store = redis_store if feature_flags.use_redis else memory_store Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "store = redis_store if feature_flags.use_redis else memory_store", "typescript": "const store = featureFlags.useRedis ? redisStore : memoryStore;"}, "id": "CC-154", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to optimize decision making: Delay decisions until the code has enough information, while keeping options isolated. Search terms that should match this issue include optimize decision making, optimize decision, decision making, system design, dependency injection.", "rule_family": "systems", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Optimize Decision Making", "topic": "Systems", "use_when": "Use this pattern when planning or reviewing code where delay decisions until the code has enough information, while keeping options isolated. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["use standards wisely", "use standards", "standards wisely", "system design", "dependency injection", "composition root", "architecture", "systems", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-155 Use Standards Wisely\nTopic: Systems\nAliases: use standards wisely, use standards, standards wisely, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to use standards wisely: Adopt standards when they add real integration value, not ceremony. Search terms that should match this issue include use standards wisely, use standards, standards wisely, system design, dependency injection.\nUse when: Use this pattern when planning or reviewing code where adopt standards when they add real integration value, not ceremony. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst event = CloudEvent.fromDomain(orderSubmitted(order));\nGood Python:\nevent = CloudEvent.from_domain(order_submitted(order))\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: review_only", "embedding_text": "Clean code pattern CC-155: Use Standards Wisely. Topic: Systems. Rule family: systems. Aliases and smell terms: use standards wisely, use standards, standards wisely, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to use standards wisely: Adopt standards when they add real integration value, not ceremony. Search terms that should match this issue include use standards wisely, use standards, standards wisely, system design, dependency injection. Use when: Use this pattern when planning or reviewing code where adopt standards when they add real integration value, not ceremony. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const event = CloudEvent.fromDomain(orderSubmitted(order)); Good Python example: event = CloudEvent.from_domain(order_submitted(order)) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "event = CloudEvent.from_domain(order_submitted(order))", "typescript": "const event = CloudEvent.fromDomain(orderSubmitted(order));"}, "id": "CC-155", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "review_only", "problem": "Code has a clean-code risk related to use standards wisely: Adopt standards when they add real integration value, not ceremony. Search terms that should match this issue include use standards wisely, use standards, standards wisely, system design, dependency injection.", "rule_family": "systems", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Use Standards Wisely", "topic": "Systems", "use_when": "Use this pattern when planning or reviewing code where adopt standards when they add real integration value, not ceremony. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["systems need dsls", "systems need", "need dsls", "system design", "dependency injection", "composition root", "architecture", "systems", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-156 Systems Need DSLs\nTopic: Systems\nAliases: systems need dsls, systems need, need dsls, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to systems need dsls: Use small domain-specific APIs to express configuration and rules clearly. Search terms that should match this issue include systems need dsls, systems need, need dsls, system design, dependency injection.\nUse when: Use this pattern when planning or reviewing code where use small domain-specific APIs to express configuration and rules clearly. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nroute.post('/orders').requiresAuth().handle(postOrder);\nGood Python:\nroute.post('/orders').requires_auth().handle(post_order)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-156: Systems Need DSLs. Topic: Systems. Rule family: systems. Aliases and smell terms: systems need dsls, systems need, need dsls, system design, dependency injection, composition root, architecture, systems, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to systems need dsls: Use small domain-specific APIs to express configuration and rules clearly. Search terms that should match this issue include systems need dsls, systems need, need dsls, system design, dependency injection. Use when: Use this pattern when planning or reviewing code where use small domain-specific APIs to express configuration and rules clearly. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: route.post('/orders').requiresAuth().handle(postOrder); Good Python example: route.post('/orders').requires_auth().handle(post_order) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "route.post('/orders').requires_auth().handle(post_order)", "typescript": "route.post('/orders').requiresAuth().handle(postOrder);"}, "id": "CC-156", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to systems need dsls: Use small domain-specific APIs to express configuration and rules clearly. Search terms that should match this issue include systems need dsls, systems need, need dsls, system design, dependency injection.", "rule_family": "systems", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Systems Need DSLs", "topic": "Systems", "use_when": "Use this pattern when planning or reviewing code where use small domain-specific APIs to express configuration and rules clearly. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["getting clean via emergent design", "getting clean", "emergent design", "simple design", "expressive code", "minimal design", "emergence", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-157 Getting Clean Via Emergent Design\nTopic: Emergence\nAliases: getting clean via emergent design, getting clean, emergent design, simple design, expressive code, minimal design, emergence, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to getting clean via emergent design: Let simple design emerge from tests and refactoring. Search terms that should match this issue include getting clean via emergent design, getting clean, emergent design, simple design, expressive code.\nUse when: Use this pattern when planning or reviewing code where let simple design emerge from tests and refactoring. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst total = priceCart(cart);\nGood Python:\ntotal = price_cart(cart)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-157: Getting Clean Via Emergent Design. Topic: Emergence. Rule family: design. Aliases and smell terms: getting clean via emergent design, getting clean, emergent design, simple design, expressive code, minimal design, emergence, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to getting clean via emergent design: Let simple design emerge from tests and refactoring. Search terms that should match this issue include getting clean via emergent design, getting clean, emergent design, simple design, expressive code. Use when: Use this pattern when planning or reviewing code where let simple design emerge from tests and refactoring. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const total = priceCart(cart); Good Python example: total = price_cart(cart) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "total = price_cart(cart)", "typescript": "const total = priceCart(cart);"}, "id": "CC-157", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to getting clean via emergent design: Let simple design emerge from tests and refactoring. Search terms that should match this issue include getting clean via emergent design, getting clean, emergent design, simple design, expressive code.", "rule_family": "design", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Getting Clean Via Emergent Design", "topic": "Emergence", "use_when": "Use this pattern when planning or reviewing code where let simple design emerge from tests and refactoring. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["runs all the tests", "runs all", "the tests", "unit test", "test smell", "test design", "test quality", "emergence", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-158 Runs All The Tests\nTopic: Emergence\nAliases: runs all the tests, runs all, the tests, unit test, test smell, test design, test quality, emergence, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to runs all the tests: A design is not safe to improve unless tests protect behavior. Search terms that should match this issue include runs all the tests, runs all, the tests, unit test, test smell.\nUse when: Use this pattern when planning or reviewing code where a design is not safe to improve unless tests protect behavior. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nexpect(calculateFee(amount)).toEqual(expectedFee);\nGood Python:\nassert calculate_fee(amount) == expected_fee\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-158: Runs All The Tests. Topic: Emergence. Rule family: tests. Aliases and smell terms: runs all the tests, runs all, the tests, unit test, test smell, test design, test quality, emergence, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to runs all the tests: A design is not safe to improve unless tests protect behavior. Search terms that should match this issue include runs all the tests, runs all, the tests, unit test, test smell. Use when: Use this pattern when planning or reviewing code where a design is not safe to improve unless tests protect behavior. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: expect(calculateFee(amount)).toEqual(expectedFee); Good Python example: assert calculate_fee(amount) == expected_fee Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "assert calculate_fee(amount) == expected_fee", "typescript": "expect(calculateFee(amount)).toEqual(expectedFee);"}, "id": "CC-158", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to runs all the tests: A design is not safe to improve unless tests protect behavior. Search terms that should match this issue include runs all the tests, runs all, the tests, unit test, test smell.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Runs All The Tests", "topic": "Emergence", "use_when": "Use this pattern when planning or reviewing code where a design is not safe to improve unless tests protect behavior. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["refactoring rules", "refactoring", "successive refinement", "incremental change", "safe change", "emergence", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-159 Refactoring Rules\nTopic: Emergence\nAliases: refactoring rules, refactoring, successive refinement, incremental change, safe change, emergence, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to refactoring rules: After tests pass, remove duplication and clarify intent. Search terms that should match this issue include refactoring rules, refactoring, successive refinement, incremental change, safe change.\nUse when: Use this pattern when planning or reviewing code where after tests pass, remove duplication and clarify intent. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst fee = feePolicy.calculate(amount);\nGood Python:\nfee = fee_policy.calculate(amount)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-159: Refactoring Rules. Topic: Emergence. Rule family: refactoring. Aliases and smell terms: refactoring rules, refactoring, successive refinement, incremental change, safe change, emergence, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to refactoring rules: After tests pass, remove duplication and clarify intent. Search terms that should match this issue include refactoring rules, refactoring, successive refinement, incremental change, safe change. Use when: Use this pattern when planning or reviewing code where after tests pass, remove duplication and clarify intent. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const fee = feePolicy.calculate(amount); Good Python example: fee = fee_policy.calculate(amount) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "fee = fee_policy.calculate(amount)", "typescript": "const fee = feePolicy.calculate(amount);"}, "id": "CC-159", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to refactoring rules: After tests pass, remove duplication and clarify intent. Search terms that should match this issue include refactoring rules, refactoring, successive refinement, incremental change, safe change.", "rule_family": "refactoring", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Refactoring Rules", "topic": "Emergence", "use_when": "Use this pattern when planning or reviewing code where after tests pass, remove duplication and clarify intent. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["no duplication", "emergence", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-160 No Duplication\nTopic: Emergence\nAliases: no duplication, emergence, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to no duplication: Eliminate duplicated knowledge, not just duplicated text. Search terms that should match this issue include no duplication, emergence, clean code, code smell, planning guidance.\nUse when: Use this pattern when planning or reviewing code where eliminate duplicated knowledge, not just duplicated text. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst canRetry = retryPolicy.shouldRetry(error, attempt);\nGood Python:\ncan_retry = retry_policy.should_retry(error, attempt)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-160: No Duplication. Topic: Emergence. Rule family: clean_code. Aliases and smell terms: no duplication, emergence, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to no duplication: Eliminate duplicated knowledge, not just duplicated text. Search terms that should match this issue include no duplication, emergence, clean code, code smell, planning guidance. Use when: Use this pattern when planning or reviewing code where eliminate duplicated knowledge, not just duplicated text. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const canRetry = retryPolicy.shouldRetry(error, attempt); Good Python example: can_retry = retry_policy.should_retry(error, attempt) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "can_retry = retry_policy.should_retry(error, attempt)", "typescript": "const canRetry = retryPolicy.shouldRetry(error, attempt);"}, "id": "CC-160", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to no duplication: Eliminate duplicated knowledge, not just duplicated text. Search terms that should match this issue include no duplication, emergence, clean code, code smell, planning guidance.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "No Duplication", "topic": "Emergence", "use_when": "Use this pattern when planning or reviewing code where eliminate duplicated knowledge, not just duplicated text. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["expressive design", "simple design", "emergent design", "expressive code", "minimal design", "emergence", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-161 Expressive Design\nTopic: Emergence\nAliases: expressive design, simple design, emergent design, expressive code, minimal design, emergence, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to expressive design: Make code reveal business intent directly. Search terms that should match this issue include expressive design, simple design, emergent design, expressive code, minimal design.\nUse when: Use this pattern when planning or reviewing code where make code reveal business intent directly. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nif (subscription.isRenewable(now)) renew(subscription);\nGood Python:\nif subscription.is_renewable(now):\n    renew(subscription)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-161: Expressive Design. Topic: Emergence. Rule family: design. Aliases and smell terms: expressive design, simple design, emergent design, expressive code, minimal design, emergence, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to expressive design: Make code reveal business intent directly. Search terms that should match this issue include expressive design, simple design, emergent design, expressive code, minimal design. Use when: Use this pattern when planning or reviewing code where make code reveal business intent directly. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: if (subscription.isRenewable(now)) renew(subscription); Good Python example: if subscription.is_renewable(now):\n    renew(subscription) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "if subscription.is_renewable(now):\n    renew(subscription)", "typescript": "if (subscription.isRenewable(now)) renew(subscription);"}, "id": "CC-161", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to expressive design: Make code reveal business intent directly. Search terms that should match this issue include expressive design, simple design, emergent design, expressive code, minimal design.", "rule_family": "design", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Expressive Design", "topic": "Emergence", "use_when": "Use this pattern when planning or reviewing code where make code reveal business intent directly. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["minimal classes and methods", "minimal classes", "and methods", "class smell", "cohesion", "single responsibility", "class design", "emergence", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-162 Minimal Classes And Methods\nTopic: Emergence\nAliases: minimal classes and methods, minimal classes, and methods, class smell, cohesion, single responsibility, class design, emergence, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to minimal classes and methods: Do not add abstractions until they earn their cost. Search terms that should match this issue include minimal classes and methods, minimal classes, and methods, class smell, cohesion.\nUse when: Use this pattern when planning or reviewing code where do not add abstractions until they earn their cost. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nfunction formatSku(sku: string): string { return sku.trim().toUpperCase(); }\nGood Python:\ndef format_sku(sku: str) -> str:\n    return sku.strip().upper()\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-162: Minimal Classes And Methods. Topic: Emergence. Rule family: classes. Aliases and smell terms: minimal classes and methods, minimal classes, and methods, class smell, cohesion, single responsibility, class design, emergence, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to minimal classes and methods: Do not add abstractions until they earn their cost. Search terms that should match this issue include minimal classes and methods, minimal classes, and methods, class smell, cohesion. Use when: Use this pattern when planning or reviewing code where do not add abstractions until they earn their cost. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: function formatSku(sku: string): string { return sku.trim().toUpperCase(); } Good Python example: def format_sku(sku: str) -> str:\n    return sku.strip().upper() Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def format_sku(sku: str) -> str:\n    return sku.strip().upper()", "typescript": "function formatSku(sku: string): string { return sku.trim().toUpperCase(); }"}, "id": "CC-162", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to minimal classes and methods: Do not add abstractions until they earn their cost. Search terms that should match this issue include minimal classes and methods, minimal classes, and methods, class smell, cohesion.", "rule_family": "classes", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Minimal Classes And Methods", "topic": "Emergence", "use_when": "Use this pattern when planning or reviewing code where do not add abstractions until they earn their cost. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["why concurrency", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-163 Why Concurrency\nTopic: Concurrency\nAliases: why concurrency, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to why concurrency: Use concurrency to improve responsiveness or throughput, not as decoration. Search terms that should match this issue include why concurrency, concurrency smell, shared state, threading, async coordination.\nUse when: Use this pattern when planning or reviewing code where use concurrency to improve responsiveness or throughput, not as decoration. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nawait Promise.all([loadProfile(id), loadPermissions(id)]);\nGood Python:\nawait asyncio.gather(load_profile(user_id), load_permissions(user_id))\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-163: Why Concurrency. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: why concurrency, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to why concurrency: Use concurrency to improve responsiveness or throughput, not as decoration. Search terms that should match this issue include why concurrency, concurrency smell, shared state, threading, async coordination. Use when: Use this pattern when planning or reviewing code where use concurrency to improve responsiveness or throughput, not as decoration. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: await Promise.all([loadProfile(id), loadPermissions(id)]); Good Python example: await asyncio.gather(load_profile(user_id), load_permissions(user_id)) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "await asyncio.gather(load_profile(user_id), load_permissions(user_id))", "typescript": "await Promise.all([loadProfile(id), loadPermissions(id)]);"}, "id": "CC-163", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to why concurrency: Use concurrency to improve responsiveness or throughput, not as decoration. Search terms that should match this issue include why concurrency, concurrency smell, shared state, threading, async coordination.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Why Concurrency", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where use concurrency to improve responsiveness or throughput, not as decoration. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["myths and misconceptions", "myths and", "and misconceptions", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-164 Myths And Misconceptions\nTopic: Concurrency\nAliases: myths and misconceptions, myths and, and misconceptions, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to myths and misconceptions: Do not assume concurrent code is automatically faster or simpler. Search terms that should match this issue include myths and misconceptions, myths and, and misconceptions, concurrency smell, shared state.\nUse when: Use this pattern when planning or reviewing code where do not assume concurrent code is automatically faster or simpler. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nconst result = await runBoundedConcurrency(tasks, 4);\nGood Python:\nresult = await run_bounded_concurrency(tasks, limit=4)\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-164: Myths And Misconceptions. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: myths and misconceptions, myths and, and misconceptions, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to myths and misconceptions: Do not assume concurrent code is automatically faster or simpler. Search terms that should match this issue include myths and misconceptions, myths and, and misconceptions, concurrency smell, shared state. Use when: Use this pattern when planning or reviewing code where do not assume concurrent code is automatically faster or simpler. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: const result = await runBoundedConcurrency(tasks, 4); Good Python example: result = await run_bounded_concurrency(tasks, limit=4) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "result = await run_bounded_concurrency(tasks, limit=4)", "typescript": "const result = await runBoundedConcurrency(tasks, 4);"}, "id": "CC-164", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to myths and misconceptions: Do not assume concurrent code is automatically faster or simpler. Search terms that should match this issue include myths and misconceptions, myths and, and misconceptions, concurrency smell, shared state.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Myths And Misconceptions", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where do not assume concurrent code is automatically faster or simpler. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["concurrency challenges", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-165 Concurrency Challenges\nTopic: Concurrency\nAliases: concurrency challenges, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to concurrency challenges: Make shared state and ordering assumptions explicit. Search terms that should match this issue include concurrency challenges, concurrency smell, shared state, threading, async coordination.\nUse when: Use this pattern when planning or reviewing code where make shared state and ordering assumptions explicit. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nawait accountLock.runExclusive(accountId, () => debit(accountId, amount));\nGood Python:\nasync with account_lock.for_key(account_id):\n    await debit(account_id, amount)\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-165: Concurrency Challenges. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: concurrency challenges, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to concurrency challenges: Make shared state and ordering assumptions explicit. Search terms that should match this issue include concurrency challenges, concurrency smell, shared state, threading, async coordination. Use when: Use this pattern when planning or reviewing code where make shared state and ordering assumptions explicit. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: await accountLock.runExclusive(accountId, () => debit(accountId, amount)); Good Python example: async with account_lock.for_key(account_id):\n    await debit(account_id, amount) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "async with account_lock.for_key(account_id):\n    await debit(account_id, amount)", "typescript": "await accountLock.runExclusive(accountId, () => debit(accountId, amount));"}, "id": "CC-165", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to concurrency challenges: Make shared state and ordering assumptions explicit. Search terms that should match this issue include concurrency challenges, concurrency smell, shared state, threading, async coordination.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Concurrency Challenges", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where make shared state and ordering assumptions explicit. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["concurrency defense principles", "concurrency defense", "defense principles", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-166 Concurrency Defense Principles\nTopic: Concurrency\nAliases: concurrency defense principles, concurrency defense, defense principles, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to concurrency defense principles: Keep concurrent responsibilities separate from business logic. Search terms that should match this issue include concurrency defense principles, concurrency defense, defense principles, concurrency smell, shared state.\nUse when: Use this pattern when planning or reviewing code where keep concurrent responsibilities separate from business logic. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nworkerPool.enqueue(() => sendReceipt(receipt));\nGood Python:\nworker_pool.enqueue(lambda: send_receipt(receipt))\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-166: Concurrency Defense Principles. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: concurrency defense principles, concurrency defense, defense principles, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to concurrency defense principles: Keep concurrent responsibilities separate from business logic. Search terms that should match this issue include concurrency defense principles, concurrency defense, defense principles, concurrency smell, shared state. Use when: Use this pattern when planning or reviewing code where keep concurrent responsibilities separate from business logic. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: workerPool.enqueue(() => sendReceipt(receipt)); Good Python example: worker_pool.enqueue(lambda: send_receipt(receipt)) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "worker_pool.enqueue(lambda: send_receipt(receipt))", "typescript": "workerPool.enqueue(() => sendReceipt(receipt));"}, "id": "CC-166", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to concurrency defense principles: Keep concurrent responsibilities separate from business logic. Search terms that should match this issue include concurrency defense principles, concurrency defense, defense principles, concurrency smell, shared state.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Concurrency Defense Principles", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where keep concurrent responsibilities separate from business logic. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["concurrency srp", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-167 Concurrency SRP\nTopic: Concurrency\nAliases: concurrency srp, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to concurrency srp: Keep thread orchestration separate from domain behavior. Search terms that should match this issue include concurrency srp, concurrency smell, shared state, threading, async coordination.\nUse when: Use this pattern when planning or reviewing code where keep thread orchestration separate from domain behavior. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nawait orderWorker.process(orderJob);\nGood Python:\nawait order_worker.process(order_job)\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-167: Concurrency SRP. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: concurrency srp, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to concurrency srp: Keep thread orchestration separate from domain behavior. Search terms that should match this issue include concurrency srp, concurrency smell, shared state, threading, async coordination. Use when: Use this pattern when planning or reviewing code where keep thread orchestration separate from domain behavior. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: await orderWorker.process(orderJob); Good Python example: await order_worker.process(order_job) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "await order_worker.process(order_job)", "typescript": "await orderWorker.process(orderJob);"}, "id": "CC-167", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to concurrency srp: Keep thread orchestration separate from domain behavior. Search terms that should match this issue include concurrency srp, concurrency smell, shared state, threading, async coordination.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Concurrency SRP", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where keep thread orchestration separate from domain behavior. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["limit scope of data", "limit scope", "of data", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-168 Limit Scope Of Data\nTopic: Concurrency\nAliases: limit scope of data, limit scope, of data, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to limit scope of data: Restrict shared mutable data to the smallest possible scope. Search terms that should match this issue include limit scope of data, limit scope, of data, concurrency smell, shared state.\nUse when: Use this pattern when planning or reviewing code where restrict shared mutable data to the smallest possible scope. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nawait lock.runExclusive(() => cache.set(key, value));\nGood Python:\nasync with lock:\n    cache[key] = value\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-168: Limit Scope Of Data. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: limit scope of data, limit scope, of data, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to limit scope of data: Restrict shared mutable data to the smallest possible scope. Search terms that should match this issue include limit scope of data, limit scope, of data, concurrency smell, shared state. Use when: Use this pattern when planning or reviewing code where restrict shared mutable data to the smallest possible scope. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: await lock.runExclusive(() => cache.set(key, value)); Good Python example: async with lock:\n    cache[key] = value Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "async with lock:\n    cache[key] = value", "typescript": "await lock.runExclusive(() => cache.set(key, value));"}, "id": "CC-168", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to limit scope of data: Restrict shared mutable data to the smallest possible scope. Search terms that should match this issue include limit scope of data, limit scope, of data, concurrency smell, shared state.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Limit Scope Of Data", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where restrict shared mutable data to the smallest possible scope. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["use copies of data", "use copies", "of data", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-169 Use Copies Of Data\nTopic: Concurrency\nAliases: use copies of data, use copies, of data, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to use copies of data: Pass immutable snapshots into concurrent work. Search terms that should match this issue include use copies of data, use copies, of data, concurrency smell, shared state.\nUse when: Use this pattern when planning or reviewing code where pass immutable snapshots into concurrent work. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nconst snapshot = structuredClone(order);\nawait processOrderSnapshot(snapshot);\nGood Python:\nsnapshot = copy.deepcopy(order)\nawait process_order_snapshot(snapshot)\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-169: Use Copies Of Data. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: use copies of data, use copies, of data, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to use copies of data: Pass immutable snapshots into concurrent work. Search terms that should match this issue include use copies of data, use copies, of data, concurrency smell, shared state. Use when: Use this pattern when planning or reviewing code where pass immutable snapshots into concurrent work. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: const snapshot = structuredClone(order);\nawait processOrderSnapshot(snapshot); Good Python example: snapshot = copy.deepcopy(order)\nawait process_order_snapshot(snapshot) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "snapshot = copy.deepcopy(order)\nawait process_order_snapshot(snapshot)", "typescript": "const snapshot = structuredClone(order);\nawait processOrderSnapshot(snapshot);"}, "id": "CC-169", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to use copies of data: Pass immutable snapshots into concurrent work. Search terms that should match this issue include use copies of data, use copies, of data, concurrency smell, shared state.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Use Copies Of Data", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where pass immutable snapshots into concurrent work. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["threads independent", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-170 Threads Independent\nTopic: Concurrency\nAliases: threads independent, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to threads independent: Design concurrent workers to share little or nothing. Search terms that should match this issue include threads independent, concurrency smell, shared state, threading, async coordination.\nUse when: Use this pattern when planning or reviewing code where design concurrent workers to share little or nothing. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nawait Promise.all(jobs.map((job) => processJob(job)));\nGood Python:\nawait asyncio.gather(*(process_job(job) for job in jobs))\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-170: Threads Independent. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: threads independent, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to threads independent: Design concurrent workers to share little or nothing. Search terms that should match this issue include threads independent, concurrency smell, shared state, threading, async coordination. Use when: Use this pattern when planning or reviewing code where design concurrent workers to share little or nothing. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: await Promise.all(jobs.map((job) => processJob(job))); Good Python example: await asyncio.gather(*(process_job(job) for job in jobs)) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "await asyncio.gather(*(process_job(job) for job in jobs))", "typescript": "await Promise.all(jobs.map((job) => processJob(job)));"}, "id": "CC-170", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to threads independent: Design concurrent workers to share little or nothing. Search terms that should match this issue include threads independent, concurrency smell, shared state, threading, async coordination.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Threads Independent", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where design concurrent workers to share little or nothing. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["know your library", "know your", "your library", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-171 Know Your Library\nTopic: Concurrency\nAliases: know your library, know your, your library, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to know your library: Use well-tested concurrency primitives instead of hand-rolled coordination. Search terms that should match this issue include know your library, know your, your library, concurrency smell, shared state.\nUse when: Use this pattern when planning or reviewing code where use well-tested concurrency primitives instead of hand-rolled coordination. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nconst queue = new PQueue({ concurrency: 4 });\nGood Python:\nqueue = asyncio.Queue(maxsize=100)\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-171: Know Your Library. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: know your library, know your, your library, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to know your library: Use well-tested concurrency primitives instead of hand-rolled coordination. Search terms that should match this issue include know your library, know your, your library, concurrency smell, shared state. Use when: Use this pattern when planning or reviewing code where use well-tested concurrency primitives instead of hand-rolled coordination. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: const queue = new PQueue({ concurrency: 4 }); Good Python example: queue = asyncio.Queue(maxsize=100) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "queue = asyncio.Queue(maxsize=100)", "typescript": "const queue = new PQueue({ concurrency: 4 });"}, "id": "CC-171", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to know your library: Use well-tested concurrency primitives instead of hand-rolled coordination. Search terms that should match this issue include know your library, know your, your library, concurrency smell, shared state.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Know Your Library", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where use well-tested concurrency primitives instead of hand-rolled coordination. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["thread-safe collections", "thread safe collections", "thread safe", "safe collections", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-172 Thread-Safe Collections\nTopic: Concurrency\nAliases: thread-safe collections, thread safe collections, thread safe, safe collections, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to thread-safe collections: Use safe collections or queues for shared work. Search terms that should match this issue include thread-safe collections, thread safe collections, thread safe, safe collections, concurrency smell.\nUse when: Use this pattern when planning or reviewing code where use safe collections or queues for shared work. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nawait workQueue.add(job);\nGood Python:\nawait work_queue.put(job)\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-172: Thread-Safe Collections. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: thread-safe collections, thread safe collections, thread safe, safe collections, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to thread-safe collections: Use safe collections or queues for shared work. Search terms that should match this issue include thread-safe collections, thread safe collections, thread safe, safe collections, concurrency smell. Use when: Use this pattern when planning or reviewing code where use safe collections or queues for shared work. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: await workQueue.add(job); Good Python example: await work_queue.put(job) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "await work_queue.put(job)", "typescript": "await workQueue.add(job);"}, "id": "CC-172", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to thread-safe collections: Use safe collections or queues for shared work. Search terms that should match this issue include thread-safe collections, thread safe collections, thread safe, safe collections, concurrency smell.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Thread-Safe Collections", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where use safe collections or queues for shared work. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["know execution models", "know execution", "execution models", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-173 Know Execution Models\nTopic: Concurrency\nAliases: know execution models, know execution, execution models, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to know execution models: Name the concurrency model so code matches the expected flow. Search terms that should match this issue include know execution models, know execution, execution models, concurrency smell, shared state.\nUse when: Use this pattern when planning or reviewing code where name the concurrency model so code matches the expected flow. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nproducer.publish(job);\nconsumer.start(processJob);\nGood Python:\nproducer.publish(job)\nconsumer.start(process_job)\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-173: Know Execution Models. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: know execution models, know execution, execution models, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to know execution models: Name the concurrency model so code matches the expected flow. Search terms that should match this issue include know execution models, know execution, execution models, concurrency smell, shared state. Use when: Use this pattern when planning or reviewing code where name the concurrency model so code matches the expected flow. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: producer.publish(job);\nconsumer.start(processJob); Good Python example: producer.publish(job)\nconsumer.start(process_job) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "producer.publish(job)\nconsumer.start(process_job)", "typescript": "producer.publish(job);\nconsumer.start(processJob);"}, "id": "CC-173", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to know execution models: Name the concurrency model so code matches the expected flow. Search terms that should match this issue include know execution models, know execution, execution models, concurrency smell, shared state.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Know Execution Models", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where name the concurrency model so code matches the expected flow. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["producer consumer", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-174 Producer Consumer\nTopic: Concurrency\nAliases: producer consumer, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to producer consumer: Separate producers of work from consumers that process work. Search terms that should match this issue include producer consumer, concurrency smell, shared state, threading, async coordination.\nUse when: Use this pattern when planning or reviewing code where separate producers of work from consumers that process work. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nawait queue.enqueue(orderJob);\nGood Python:\nawait queue.put(order_job)\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-174: Producer Consumer. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: producer consumer, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to producer consumer: Separate producers of work from consumers that process work. Search terms that should match this issue include producer consumer, concurrency smell, shared state, threading, async coordination. Use when: Use this pattern when planning or reviewing code where separate producers of work from consumers that process work. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: await queue.enqueue(orderJob); Good Python example: await queue.put(order_job) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "await queue.put(order_job)", "typescript": "await queue.enqueue(orderJob);"}, "id": "CC-174", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to producer consumer: Separate producers of work from consumers that process work. Search terms that should match this issue include producer consumer, concurrency smell, shared state, threading, async coordination.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Producer Consumer", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where separate producers of work from consumers that process work. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["readers writers", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-175 Readers Writers\nTopic: Concurrency\nAliases: readers writers, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to readers writers: Use read/write locks when many readers and few writers share state. Search terms that should match this issue include readers writers, concurrency smell, shared state, threading, async coordination.\nUse when: Use this pattern when planning or reviewing code where use read/write locks when many readers and few writers share state. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nawait readWriteLock.read(() => cache.get(key));\nGood Python:\nasync with read_write_lock.read():\n    value = cache[key]\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-175: Readers Writers. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: readers writers, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to readers writers: Use read/write locks when many readers and few writers share state. Search terms that should match this issue include readers writers, concurrency smell, shared state, threading, async coordination. Use when: Use this pattern when planning or reviewing code where use read/write locks when many readers and few writers share state. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: await readWriteLock.read(() => cache.get(key)); Good Python example: async with read_write_lock.read():\n    value = cache[key] Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "async with read_write_lock.read():\n    value = cache[key]", "typescript": "await readWriteLock.read(() => cache.get(key));"}, "id": "CC-175", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to readers writers: Use read/write locks when many readers and few writers share state. Search terms that should match this issue include readers writers, concurrency smell, shared state, threading, async coordination.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Readers Writers", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where use read/write locks when many readers and few writers share state. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["dining philosophers", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-176 Dining Philosophers\nTopic: Concurrency\nAliases: dining philosophers, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to dining philosophers: Acquire multiple resources in a stable order to avoid deadlocks. Search terms that should match this issue include dining philosophers, concurrency smell, shared state, threading, async coordination.\nUse when: Use this pattern when planning or reviewing code where acquire multiple resources in a stable order to avoid deadlocks. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nconst [first, second] = orderedLocks(accountA, accountB);\nGood Python:\nfirst, second = ordered_locks(account_a, account_b)\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-176: Dining Philosophers. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: dining philosophers, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to dining philosophers: Acquire multiple resources in a stable order to avoid deadlocks. Search terms that should match this issue include dining philosophers, concurrency smell, shared state, threading, async coordination. Use when: Use this pattern when planning or reviewing code where acquire multiple resources in a stable order to avoid deadlocks. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: const [first, second] = orderedLocks(accountA, accountB); Good Python example: first, second = ordered_locks(account_a, account_b) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "first, second = ordered_locks(account_a, account_b)", "typescript": "const [first, second] = orderedLocks(accountA, accountB);"}, "id": "CC-176", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to dining philosophers: Acquire multiple resources in a stable order to avoid deadlocks. Search terms that should match this issue include dining philosophers, concurrency smell, shared state, threading, async coordination.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Dining Philosophers", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where acquire multiple resources in a stable order to avoid deadlocks. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["dependencies between synchronized methods", "dependencies between", "synchronized methods", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-177 Dependencies Between Synchronized Methods\nTopic: Concurrency\nAliases: dependencies between synchronized methods, dependencies between, synchronized methods, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to dependencies between synchronized methods: Avoid requiring callers to coordinate multiple locked methods correctly. Search terms that should match this issue include dependencies between synchronized methods, dependencies between, synchronized methods, concurrency smell, shared state.\nUse when: Use this pattern when planning or reviewing code where avoid requiring callers to coordinate multiple locked methods correctly. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nawait accountStore.transfer(fromId, toId, amount);\nGood Python:\nawait account_store.transfer(from_id, to_id, amount)\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-177: Dependencies Between Synchronized Methods. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: dependencies between synchronized methods, dependencies between, synchronized methods, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to dependencies between synchronized methods: Avoid requiring callers to coordinate multiple locked methods correctly. Search terms that should match this issue include dependencies between synchronized methods, dependencies between, synchronized methods, concurrency smell, shared state. Use when: Use this pattern when planning or reviewing code where avoid requiring callers to coordinate multiple locked methods correctly. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: await accountStore.transfer(fromId, toId, amount); Good Python example: await account_store.transfer(from_id, to_id, amount) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "await account_store.transfer(from_id, to_id, amount)", "typescript": "await accountStore.transfer(fromId, toId, amount);"}, "id": "CC-177", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to dependencies between synchronized methods: Avoid requiring callers to coordinate multiple locked methods correctly. Search terms that should match this issue include dependencies between synchronized methods, dependencies between, synchronized methods, concurrency smell, shared state.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Dependencies Between Synchronized Methods", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where avoid requiring callers to coordinate multiple locked methods correctly. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["small synchronized sections", "small synchronized", "synchronized sections", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-178 Small Synchronized Sections\nTopic: Concurrency\nAliases: small synchronized sections, small synchronized, synchronized sections, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to small synchronized sections: Keep locked sections minimal and side-effect focused. Search terms that should match this issue include small synchronized sections, small synchronized, synchronized sections, concurrency smell, shared state.\nUse when: Use this pattern when planning or reviewing code where keep locked sections minimal and side-effect focused. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nawait lock.runExclusive(() => updateBalance(accountId, amount));\nGood Python:\nasync with lock:\n    update_balance(account_id, amount)\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-178: Small Synchronized Sections. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: small synchronized sections, small synchronized, synchronized sections, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to small synchronized sections: Keep locked sections minimal and side-effect focused. Search terms that should match this issue include small synchronized sections, small synchronized, synchronized sections, concurrency smell, shared state. Use when: Use this pattern when planning or reviewing code where keep locked sections minimal and side-effect focused. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: await lock.runExclusive(() => updateBalance(accountId, amount)); Good Python example: async with lock:\n    update_balance(account_id, amount) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "async with lock:\n    update_balance(account_id, amount)", "typescript": "await lock.runExclusive(() => updateBalance(accountId, amount));"}, "id": "CC-178", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to small synchronized sections: Keep locked sections minimal and side-effect focused. Search terms that should match this issue include small synchronized sections, small synchronized, synchronized sections, concurrency smell, shared state.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Small Synchronized Sections", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where keep locked sections minimal and side-effect focused. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["correct shutdown is hard", "correct shutdown", "is hard", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-179 Correct Shutdown Is Hard\nTopic: Concurrency\nAliases: correct shutdown is hard, correct shutdown, is hard, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to correct shutdown is hard: Make shutdown explicit and testable. Search terms that should match this issue include correct shutdown is hard, correct shutdown, is hard, concurrency smell, shared state.\nUse when: Use this pattern when planning or reviewing code where make shutdown explicit and testable. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nawait worker.stop({ drain: true, timeoutMs: 5000 });\nGood Python:\nawait worker.stop(drain=True, timeout=5)\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-179: Correct Shutdown Is Hard. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: correct shutdown is hard, correct shutdown, is hard, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to correct shutdown is hard: Make shutdown explicit and testable. Search terms that should match this issue include correct shutdown is hard, correct shutdown, is hard, concurrency smell, shared state. Use when: Use this pattern when planning or reviewing code where make shutdown explicit and testable. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: await worker.stop({ drain: true, timeoutMs: 5000 }); Good Python example: await worker.stop(drain=True, timeout=5) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "await worker.stop(drain=True, timeout=5)", "typescript": "await worker.stop({ drain: true, timeoutMs: 5000 });"}, "id": "CC-179", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to correct shutdown is hard: Make shutdown explicit and testable. Search terms that should match this issue include correct shutdown is hard, correct shutdown, is hard, concurrency smell, shared state.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Correct Shutdown Is Hard", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where make shutdown explicit and testable. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["testing threaded code", "testing threaded", "threaded code", "unit test", "test smell", "test design", "test quality", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-180 Testing Threaded Code\nTopic: Concurrency\nAliases: testing threaded code, testing threaded, threaded code, unit test, test smell, test design, test quality, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to testing threaded code: Stress concurrency with repeatable tests and controlled scheduling. Search terms that should match this issue include testing threaded code, testing threaded, threaded code, unit test, test smell.\nUse when: Use this pattern when planning or reviewing code where stress concurrency with repeatable tests and controlled scheduling. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nawait runRaceTest(() => transferBothWays(accounts));\nGood Python:\nawait run_race_test(lambda: transfer_both_ways(accounts))\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-180: Testing Threaded Code. Topic: Concurrency. Rule family: tests. Aliases and smell terms: testing threaded code, testing threaded, threaded code, unit test, test smell, test design, test quality, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to testing threaded code: Stress concurrency with repeatable tests and controlled scheduling. Search terms that should match this issue include testing threaded code, testing threaded, threaded code, unit test, test smell. Use when: Use this pattern when planning or reviewing code where stress concurrency with repeatable tests and controlled scheduling. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: await runRaceTest(() => transferBothWays(accounts)); Good Python example: await run_race_test(lambda: transfer_both_ways(accounts)) Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "await run_race_test(lambda: transfer_both_ways(accounts))", "typescript": "await runRaceTest(() => transferBothWays(accounts));"}, "id": "CC-180", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to testing threaded code: Stress concurrency with repeatable tests and controlled scheduling. Search terms that should match this issue include testing threaded code, testing threaded, threaded code, unit test, test smell.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Testing Threaded Code", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where stress concurrency with repeatable tests and controlled scheduling. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["spurious failures are threading issues", "spurious failures", "threading issues", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-181 Spurious Failures Are Threading Issues\nTopic: Concurrency\nAliases: spurious failures are threading issues, spurious failures, threading issues, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to spurious failures are threading issues: Treat flaky concurrent failures as real signals. Search terms that should match this issue include spurious failures are threading issues, spurious failures, threading issues, concurrency smell, shared state.\nUse when: Use this pattern when planning or reviewing code where treat flaky concurrent failures as real signals. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nawait repeat(100, () => transferScenario());\nGood Python:\nawait repeat(100, transfer_scenario)\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-181: Spurious Failures Are Threading Issues. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: spurious failures are threading issues, spurious failures, threading issues, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to spurious failures are threading issues: Treat flaky concurrent failures as real signals. Search terms that should match this issue include spurious failures are threading issues, spurious failures, threading issues, concurrency smell, shared state. Use when: Use this pattern when planning or reviewing code where treat flaky concurrent failures as real signals. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: await repeat(100, () => transferScenario()); Good Python example: await repeat(100, transfer_scenario) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "await repeat(100, transfer_scenario)", "typescript": "await repeat(100, () => transferScenario());"}, "id": "CC-181", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to spurious failures are threading issues: Treat flaky concurrent failures as real signals. Search terms that should match this issue include spurious failures are threading issues, spurious failures, threading issues, concurrency smell, shared state.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Spurious Failures Are Threading Issues", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where treat flaky concurrent failures as real signals. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["get nonthreaded code working first", "get nonthreaded", "working first", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-182 Get Nonthreaded Code Working First\nTopic: Concurrency\nAliases: get nonthreaded code working first, get nonthreaded, working first, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to get nonthreaded code working first: Verify domain behavior before adding concurrent execution. Search terms that should match this issue include get nonthreaded code working first, get nonthreaded, working first, concurrency smell, shared state.\nUse when: Use this pattern when planning or reviewing code where verify domain behavior before adding concurrent execution. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nexpect(applyPayment(order, payment)).toEqual(paidOrder);\nGood Python:\nassert apply_payment(order, payment) == paid_order\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-182: Get Nonthreaded Code Working First. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: get nonthreaded code working first, get nonthreaded, working first, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to get nonthreaded code working first: Verify domain behavior before adding concurrent execution. Search terms that should match this issue include get nonthreaded code working first, get nonthreaded, working first, concurrency smell, shared state. Use when: Use this pattern when planning or reviewing code where verify domain behavior before adding concurrent execution. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: expect(applyPayment(order, payment)).toEqual(paidOrder); Good Python example: assert apply_payment(order, payment) == paid_order Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "assert apply_payment(order, payment) == paid_order", "typescript": "expect(applyPayment(order, payment)).toEqual(paidOrder);"}, "id": "CC-182", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to get nonthreaded code working first: Verify domain behavior before adding concurrent execution. Search terms that should match this issue include get nonthreaded code working first, get nonthreaded, working first, concurrency smell, shared state.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Get Nonthreaded Code Working First", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where verify domain behavior before adding concurrent execution. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["threaded code pluggable", "threaded code", "code pluggable", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-183 Threaded Code Pluggable\nTopic: Concurrency\nAliases: threaded code pluggable, threaded code, code pluggable, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to threaded code pluggable: Make concurrency strategy replaceable in tests. Search terms that should match this issue include threaded code pluggable, threaded code, code pluggable, concurrency smell, shared state.\nUse when: Use this pattern when planning or reviewing code where make concurrency strategy replaceable in tests. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nconst executor = new InlineExecutor();\nawait service.run(executor);\nGood Python:\nexecutor = InlineExecutor()\nawait service.run(executor)\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-183: Threaded Code Pluggable. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: threaded code pluggable, threaded code, code pluggable, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to threaded code pluggable: Make concurrency strategy replaceable in tests. Search terms that should match this issue include threaded code pluggable, threaded code, code pluggable, concurrency smell, shared state. Use when: Use this pattern when planning or reviewing code where make concurrency strategy replaceable in tests. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: const executor = new InlineExecutor();\nawait service.run(executor); Good Python example: executor = InlineExecutor()\nawait service.run(executor) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "executor = InlineExecutor()\nawait service.run(executor)", "typescript": "const executor = new InlineExecutor();\nawait service.run(executor);"}, "id": "CC-183", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to threaded code pluggable: Make concurrency strategy replaceable in tests. Search terms that should match this issue include threaded code pluggable, threaded code, code pluggable, concurrency smell, shared state.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Threaded Code Pluggable", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where make concurrency strategy replaceable in tests. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["threaded code tunable", "threaded code", "code tunable", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-184 Threaded Code Tunable\nTopic: Concurrency\nAliases: threaded code tunable, threaded code, code tunable, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to threaded code tunable: Expose safe tuning parameters at configuration boundaries. Search terms that should match this issue include threaded code tunable, threaded code, code tunable, concurrency smell, shared state.\nUse when: Use this pattern when planning or reviewing code where expose safe tuning parameters at configuration boundaries. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nconst pool = new WorkerPool({ concurrency: settings.workerCount });\nGood Python:\npool = WorkerPool(concurrency=settings.worker_count)\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-184: Threaded Code Tunable. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: threaded code tunable, threaded code, code tunable, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to threaded code tunable: Expose safe tuning parameters at configuration boundaries. Search terms that should match this issue include threaded code tunable, threaded code, code tunable, concurrency smell, shared state. Use when: Use this pattern when planning or reviewing code where expose safe tuning parameters at configuration boundaries. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: const pool = new WorkerPool({ concurrency: settings.workerCount }); Good Python example: pool = WorkerPool(concurrency=settings.worker_count) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "pool = WorkerPool(concurrency=settings.worker_count)", "typescript": "const pool = new WorkerPool({ concurrency: settings.workerCount });"}, "id": "CC-184", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to threaded code tunable: Expose safe tuning parameters at configuration boundaries. Search terms that should match this issue include threaded code tunable, threaded code, code tunable, concurrency smell, shared state.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Threaded Code Tunable", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where expose safe tuning parameters at configuration boundaries. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["run more threads than processors", "run more", "than processors", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-185 Run More Threads Than Processors\nTopic: Concurrency\nAliases: run more threads than processors, run more, than processors, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to run more threads than processors: Stress tests should oversubscribe work to expose scheduling defects. Search terms that should match this issue include run more threads than processors, run more, than processors, concurrency smell, shared state.\nUse when: Use this pattern when planning or reviewing code where stress tests should oversubscribe work to expose scheduling defects. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nawait runWithConcurrency(tasks, cpuCount() * 4);\nGood Python:\nawait run_with_concurrency(tasks, os.cpu_count() * 4)\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-185: Run More Threads Than Processors. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: run more threads than processors, run more, than processors, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to run more threads than processors: Stress tests should oversubscribe work to expose scheduling defects. Search terms that should match this issue include run more threads than processors, run more, than processors, concurrency smell, shared state. Use when: Use this pattern when planning or reviewing code where stress tests should oversubscribe work to expose scheduling defects. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: await runWithConcurrency(tasks, cpuCount() * 4); Good Python example: await run_with_concurrency(tasks, os.cpu_count() * 4) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "await run_with_concurrency(tasks, os.cpu_count() * 4)", "typescript": "await runWithConcurrency(tasks, cpuCount() * 4);"}, "id": "CC-185", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to run more threads than processors: Stress tests should oversubscribe work to expose scheduling defects. Search terms that should match this issue include run more threads than processors, run more, than processors, concurrency smell, shared state.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Run More Threads Than Processors", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where stress tests should oversubscribe work to expose scheduling defects. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["run on different platforms", "run on", "different platforms", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-186 Run On Different Platforms\nTopic: Concurrency\nAliases: run on different platforms, run on, different platforms, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to run on different platforms: Avoid platform-specific concurrency assumptions. Search terms that should match this issue include run on different platforms, run on, different platforms, concurrency smell, shared state.\nUse when: Use this pattern when planning or reviewing code where avoid platform-specific concurrency assumptions. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nawait portableScheduler.run(job);\nGood Python:\nawait portable_scheduler.run(job)\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-186: Run On Different Platforms. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: run on different platforms, run on, different platforms, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to run on different platforms: Avoid platform-specific concurrency assumptions. Search terms that should match this issue include run on different platforms, run on, different platforms, concurrency smell, shared state. Use when: Use this pattern when planning or reviewing code where avoid platform-specific concurrency assumptions. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: await portableScheduler.run(job); Good Python example: await portable_scheduler.run(job) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "await portable_scheduler.run(job)", "typescript": "await portableScheduler.run(job);"}, "id": "CC-186", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to run on different platforms: Avoid platform-specific concurrency assumptions. Search terms that should match this issue include run on different platforms, run on, different platforms, concurrency smell, shared state.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Run On Different Platforms", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where avoid platform-specific concurrency assumptions. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["instrument to force failures", "instrument to", "force failures", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-187 Instrument To Force Failures\nTopic: Concurrency\nAliases: instrument to force failures, instrument to, force failures, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to instrument to force failures: Add test-only hooks to widen race windows intentionally. Search terms that should match this issue include instrument to force failures, instrument to, force failures, concurrency smell, shared state.\nUse when: Use this pattern when planning or reviewing code where add test-only hooks to widen race windows intentionally. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nawait scheduler.yieldAt('after-read');\nGood Python:\nawait scheduler.yield_at('after_read')\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-187: Instrument To Force Failures. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: instrument to force failures, instrument to, force failures, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to instrument to force failures: Add test-only hooks to widen race windows intentionally. Search terms that should match this issue include instrument to force failures, instrument to, force failures, concurrency smell, shared state. Use when: Use this pattern when planning or reviewing code where add test-only hooks to widen race windows intentionally. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: await scheduler.yieldAt('after-read'); Good Python example: await scheduler.yield_at('after_read') Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "await scheduler.yield_at('after_read')", "typescript": "await scheduler.yieldAt('after-read');"}, "id": "CC-187", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to instrument to force failures: Add test-only hooks to widen race windows intentionally. Search terms that should match this issue include instrument to force failures, instrument to, force failures, concurrency smell, shared state.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Instrument To Force Failures", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where add test-only hooks to widen race windows intentionally. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["hand coded instrumentation", "hand coded", "coded instrumentation", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-188 Hand Coded Instrumentation\nTopic: Concurrency\nAliases: hand coded instrumentation, hand coded, coded instrumentation, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to hand coded instrumentation: Use explicit test probes when diagnosing races. Search terms that should match this issue include hand coded instrumentation, hand coded, coded instrumentation, concurrency smell, shared state.\nUse when: Use this pattern when planning or reviewing code where use explicit test probes when diagnosing races. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\ntestProbe.pause('before-write');\nGood Python:\ntest_probe.pause('before_write')\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-188: Hand Coded Instrumentation. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: hand coded instrumentation, hand coded, coded instrumentation, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to hand coded instrumentation: Use explicit test probes when diagnosing races. Search terms that should match this issue include hand coded instrumentation, hand coded, coded instrumentation, concurrency smell, shared state. Use when: Use this pattern when planning or reviewing code where use explicit test probes when diagnosing races. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: testProbe.pause('before-write'); Good Python example: test_probe.pause('before_write') Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "test_probe.pause('before_write')", "typescript": "testProbe.pause('before-write');"}, "id": "CC-188", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to hand coded instrumentation: Use explicit test probes when diagnosing races. Search terms that should match this issue include hand coded instrumentation, hand coded, coded instrumentation, concurrency smell, shared state.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Hand Coded Instrumentation", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where use explicit test probes when diagnosing races. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["automated instrumentation", "concurrency smell", "shared state", "threading", "async coordination", "concurrency", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.", "bad_examples": {"python": "shared_cache[key] = await load_value(key)", "typescript": "sharedCache[key] = await loadValue(key);"}, "display_text": "CC-189 Automated Instrumentation\nTopic: Concurrency\nAliases: automated instrumentation, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to automated instrumentation: Use tools that vary scheduling automatically when possible. Search terms that should match this issue include automated instrumentation, concurrency smell, shared state, threading, async coordination.\nUse when: Use this pattern when planning or reviewing code where use tools that vary scheduling automatically when possible. It is especially relevant when async or threaded code shares mutable state or depends on ordering.\nAvoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity.\nGood TypeScript:\nawait concurrencyFuzzer.run(transferScenario);\nGood Python:\nawait concurrency_fuzzer.run(transfer_scenario)\nBad TypeScript:\nsharedCache[key] = await loadValue(key);\nBad Python:\nshared_cache[key] = await load_value(key)\nLint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.\nLintability: high", "embedding_text": "Clean code pattern CC-189: Automated Instrumentation. Topic: Concurrency. Rule family: concurrency. Aliases and smell terms: automated instrumentation, concurrency smell, shared state, threading, async coordination, concurrency, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to automated instrumentation: Use tools that vary scheduling automatically when possible. Search terms that should match this issue include automated instrumentation, concurrency smell, shared state, threading, async coordination. Use when: Use this pattern when planning or reviewing code where use tools that vary scheduling automatically when possible. It is especially relevant when async or threaded code shares mutable state or depends on ordering. Avoid when: Avoid adding concurrency abstractions unless shared state, ordering, or throughput needs justify the extra complexity. Lint candidates: Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots.. Good TypeScript example: await concurrencyFuzzer.run(transferScenario); Good Python example: await concurrency_fuzzer.run(transfer_scenario) Bad TypeScript example: sharedCache[key] = await loadValue(key); Bad Python example: shared_cache[key] = await load_value(key)", "good_examples": {"python": "await concurrency_fuzzer.run(transfer_scenario)", "typescript": "await concurrencyFuzzer.run(transferScenario);"}, "id": "CC-189", "lint_candidates": ["Flag shared mutable state in async/concurrent code and require named locks, queues, or immutable snapshots."], "lintability": "high", "problem": "Code has a clean-code risk related to automated instrumentation: Use tools that vary scheduling automatically when possible. Search terms that should match this issue include automated instrumentation, concurrency smell, shared state, threading, async coordination.", "rule_family": "concurrency", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Automated Instrumentation", "topic": "Concurrency", "use_when": "Use this pattern when planning or reviewing code where use tools that vary scheduling automatically when possible. It is especially relevant when async or threaded code shares mutable state or depends on ordering."}
+{"aliases": ["args implementation", "successive refinement", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-190 Args Implementation\nTopic: Successive Refinement\nAliases: args implementation, successive refinement, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to args implementation: Let a working parser evolve through tests and small refactors. Search terms that should match this issue include args implementation, successive refinement, clean code, code smell, planning guidance.\nUse when: Use this pattern when planning or reviewing code where let a working parser evolve through tests and small refactors. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst args = parseArgs(schema, argv);\nGood Python:\nargs = parse_args(schema, argv)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-190: Args Implementation. Topic: Successive Refinement. Rule family: clean_code. Aliases and smell terms: args implementation, successive refinement, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to args implementation: Let a working parser evolve through tests and small refactors. Search terms that should match this issue include args implementation, successive refinement, clean code, code smell, planning guidance. Use when: Use this pattern when planning or reviewing code where let a working parser evolve through tests and small refactors. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const args = parseArgs(schema, argv); Good Python example: args = parse_args(schema, argv) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "args = parse_args(schema, argv)", "typescript": "const args = parseArgs(schema, argv);"}, "id": "CC-190", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to args implementation: Let a working parser evolve through tests and small refactors. Search terms that should match this issue include args implementation, successive refinement, clean code, code smell, planning guidance.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Args Implementation", "topic": "Successive Refinement", "use_when": "Use this pattern when planning or reviewing code where let a working parser evolve through tests and small refactors. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["how did i do this", "how did", "do this", "successive refinement", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-191 How Did I Do This\nTopic: Successive Refinement\nAliases: how did i do this, how did, do this, successive refinement, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to how did i do this: Make refactoring steps understandable by keeping behavior protected. Search terms that should match this issue include how did i do this, how did, do this, successive refinement, clean code.\nUse when: Use this pattern when planning or reviewing code where make refactoring steps understandable by keeping behavior protected. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nexpect(parseArgs(schema, ['--port', '8080']).port).toBe(8080);\nGood Python:\nassert parse_args(schema, ['--port', '8080']).port == 8080\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: review_only", "embedding_text": "Clean code pattern CC-191: How Did I Do This. Topic: Successive Refinement. Rule family: clean_code. Aliases and smell terms: how did i do this, how did, do this, successive refinement, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to how did i do this: Make refactoring steps understandable by keeping behavior protected. Search terms that should match this issue include how did i do this, how did, do this, successive refinement, clean code. Use when: Use this pattern when planning or reviewing code where make refactoring steps understandable by keeping behavior protected. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: expect(parseArgs(schema, ['--port', '8080']).port).toBe(8080); Good Python example: assert parse_args(schema, ['--port', '8080']).port == 8080 Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "assert parse_args(schema, ['--port', '8080']).port == 8080", "typescript": "expect(parseArgs(schema, ['--port', '8080']).port).toBe(8080);"}, "id": "CC-191", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "review_only", "problem": "Code has a clean-code risk related to how did i do this: Make refactoring steps understandable by keeping behavior protected. Search terms that should match this issue include how did i do this, how did, do this, successive refinement, clean code.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "How Did I Do This", "topic": "Successive Refinement", "use_when": "Use this pattern when planning or reviewing code where make refactoring steps understandable by keeping behavior protected. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["args rough draft", "args rough", "rough draft", "successive refinement", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-192 Args Rough Draft\nTopic: Successive Refinement\nAliases: args rough draft, args rough, rough draft, successive refinement, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to args rough draft: Accept that first drafts are rough, then refine with tests. Search terms that should match this issue include args rough draft, args rough, rough draft, successive refinement, clean code.\nUse when: Use this pattern when planning or reviewing code where accept that first drafts are rough, then refine with tests. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst parsed = roughParseArgs(argv);\nGood Python:\nparsed = rough_parse_args(argv)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: review_only", "embedding_text": "Clean code pattern CC-192: Args Rough Draft. Topic: Successive Refinement. Rule family: clean_code. Aliases and smell terms: args rough draft, args rough, rough draft, successive refinement, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to args rough draft: Accept that first drafts are rough, then refine with tests. Search terms that should match this issue include args rough draft, args rough, rough draft, successive refinement, clean code. Use when: Use this pattern when planning or reviewing code where accept that first drafts are rough, then refine with tests. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const parsed = roughParseArgs(argv); Good Python example: parsed = rough_parse_args(argv) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "parsed = rough_parse_args(argv)", "typescript": "const parsed = roughParseArgs(argv);"}, "id": "CC-192", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "review_only", "problem": "Code has a clean-code risk related to args rough draft: Accept that first drafts are rough, then refine with tests. Search terms that should match this issue include args rough draft, args rough, rough draft, successive refinement, clean code.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Args Rough Draft", "topic": "Successive Refinement", "use_when": "Use this pattern when planning or reviewing code where accept that first drafts are rough, then refine with tests. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["so i stopped", "so i", "i stopped", "successive refinement", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-193 So I Stopped\nTopic: Successive Refinement\nAliases: so i stopped, so i, i stopped, successive refinement, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to so i stopped: Pause when code resists change and improve structure before adding more behavior. Search terms that should match this issue include so i stopped, so i, i stopped, successive refinement, clean code.\nUse when: Use this pattern when planning or reviewing code where pause when code resists change and improve structure before adding more behavior. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst parser = new ArgsParser(schema);\nGood Python:\nparser = ArgsParser(schema)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-193: So I Stopped. Topic: Successive Refinement. Rule family: clean_code. Aliases and smell terms: so i stopped, so i, i stopped, successive refinement, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to so i stopped: Pause when code resists change and improve structure before adding more behavior. Search terms that should match this issue include so i stopped, so i, i stopped, successive refinement, clean code. Use when: Use this pattern when planning or reviewing code where pause when code resists change and improve structure before adding more behavior. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const parser = new ArgsParser(schema); Good Python example: parser = ArgsParser(schema) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "parser = ArgsParser(schema)", "typescript": "const parser = new ArgsParser(schema);"}, "id": "CC-193", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to so i stopped: Pause when code resists change and improve structure before adding more behavior. Search terms that should match this issue include so i stopped, so i, i stopped, successive refinement, clean code.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "So I Stopped", "topic": "Successive Refinement", "use_when": "Use this pattern when planning or reviewing code where pause when code resists change and improve structure before adding more behavior. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["on incrementalism", "successive refinement", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-194 On Incrementalism\nTopic: Successive Refinement\nAliases: on incrementalism, successive refinement, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to on incrementalism: Move in small verified steps rather than one large rewrite. Search terms that should match this issue include on incrementalism, successive refinement, clean code, code smell, planning guidance.\nUse when: Use this pattern when planning or reviewing code where move in small verified steps rather than one large rewrite. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst option = parseBooleanOption(token);\nGood Python:\noption = parse_boolean_option(token)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-194: On Incrementalism. Topic: Successive Refinement. Rule family: clean_code. Aliases and smell terms: on incrementalism, successive refinement, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to on incrementalism: Move in small verified steps rather than one large rewrite. Search terms that should match this issue include on incrementalism, successive refinement, clean code, code smell, planning guidance. Use when: Use this pattern when planning or reviewing code where move in small verified steps rather than one large rewrite. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const option = parseBooleanOption(token); Good Python example: option = parse_boolean_option(token) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "option = parse_boolean_option(token)", "typescript": "const option = parseBooleanOption(token);"}, "id": "CC-194", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to on incrementalism: Move in small verified steps rather than one large rewrite. Search terms that should match this issue include on incrementalism, successive refinement, clean code, code smell, planning guidance.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "On Incrementalism", "topic": "Successive Refinement", "use_when": "Use this pattern when planning or reviewing code where move in small verified steps rather than one large rewrite. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["string arguments", "argument smell", "parameter smell", "call site clarity", "function signature", "successive refinement", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid wrapping parameters when the existing call is already clear and the values do not form a stable concept.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-195 String Arguments\nTopic: Successive Refinement\nAliases: string arguments, argument smell, parameter smell, call site clarity, function signature, successive refinement, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to string arguments: Add new argument types by extending a clear parser structure. Search terms that should match this issue include string arguments, argument smell, parameter smell, call site clarity, function signature.\nUse when: Use this pattern when planning or reviewing code where add new argument types by extending a clear parser structure. It is especially relevant when a call site is unclear or a parameter changes behavior by mode.\nAvoid when: Avoid wrapping parameters when the existing call is already clear and the values do not form a stable concept.\nGood TypeScript:\nschema.addString('output');\nGood Python:\nschema.add_string('output')\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-195: String Arguments. Topic: Successive Refinement. Rule family: function_arguments. Aliases and smell terms: string arguments, argument smell, parameter smell, call site clarity, function signature, successive refinement, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to string arguments: Add new argument types by extending a clear parser structure. Search terms that should match this issue include string arguments, argument smell, parameter smell, call site clarity, function signature. Use when: Use this pattern when planning or reviewing code where add new argument types by extending a clear parser structure. It is especially relevant when a call site is unclear or a parameter changes behavior by mode. Avoid when: Avoid wrapping parameters when the existing call is already clear and the values do not form a stable concept. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: schema.addString('output'); Good Python example: schema.add_string('output') Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "schema.add_string('output')", "typescript": "schema.addString('output');"}, "id": "CC-195", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to string arguments: Add new argument types by extending a clear parser structure. Search terms that should match this issue include string arguments, argument smell, parameter smell, call site clarity, function signature.", "rule_family": "function_arguments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "String Arguments", "topic": "Successive Refinement", "use_when": "Use this pattern when planning or reviewing code where add new argument types by extending a clear parser structure. It is especially relevant when a call site is unclear or a parameter changes behavior by mode."}
+{"aliases": ["junit framework", "junit internals", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-196 JUnit Framework\nTopic: JUnit Internals\nAliases: junit framework, junit internals, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to junit framework: Study framework internals by identifying small roles and collaborations. Search terms that should match this issue include junit framework, junit internals, clean code, code smell, planning guidance.\nUse when: Use this pattern when planning or reviewing code where study framework internals by identifying small roles and collaborations. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst result = testRunner.run(testCase);\nGood Python:\nresult = test_runner.run(test_case)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-196: JUnit Framework. Topic: JUnit Internals. Rule family: clean_code. Aliases and smell terms: junit framework, junit internals, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to junit framework: Study framework internals by identifying small roles and collaborations. Search terms that should match this issue include junit framework, junit internals, clean code, code smell, planning guidance. Use when: Use this pattern when planning or reviewing code where study framework internals by identifying small roles and collaborations. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const result = testRunner.run(testCase); Good Python example: result = test_runner.run(test_case) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "result = test_runner.run(test_case)", "typescript": "const result = testRunner.run(testCase);"}, "id": "CC-196", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to junit framework: Study framework internals by identifying small roles and collaborations. Search terms that should match this issue include junit framework, junit internals, clean code, code smell, planning guidance.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "JUnit Framework", "topic": "JUnit Internals", "use_when": "Use this pattern when planning or reviewing code where study framework internals by identifying small roles and collaborations. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["first make it work", "first make", "it work", "refactoring", "successive refinement", "incremental change", "safe change", "refactoring serialdate", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-197 First Make It Work\nTopic: Refactoring SerialDate\nAliases: first make it work, first make, it work, refactoring, successive refinement, incremental change, safe change, refactoring serialdate, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to first make it work: Before refactoring, pin current behavior with tests. Search terms that should match this issue include first make it work, first make, it work, refactoring, successive refinement.\nUse when: Use this pattern when planning or reviewing code where before refactoring, pin current behavior with tests. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nexpect(addDays(date, 1)).toEqual(nextDate);\nGood Python:\nassert add_days(date, 1) == next_date\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-197: First Make It Work. Topic: Refactoring SerialDate. Rule family: refactoring. Aliases and smell terms: first make it work, first make, it work, refactoring, successive refinement, incremental change, safe change, refactoring serialdate, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to first make it work: Before refactoring, pin current behavior with tests. Search terms that should match this issue include first make it work, first make, it work, refactoring, successive refinement. Use when: Use this pattern when planning or reviewing code where before refactoring, pin current behavior with tests. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: expect(addDays(date, 1)).toEqual(nextDate); Good Python example: assert add_days(date, 1) == next_date Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "assert add_days(date, 1) == next_date", "typescript": "expect(addDays(date, 1)).toEqual(nextDate);"}, "id": "CC-197", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to first make it work: Before refactoring, pin current behavior with tests. Search terms that should match this issue include first make it work, first make, it work, refactoring, successive refinement.", "rule_family": "refactoring", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "First Make It Work", "topic": "Refactoring SerialDate", "use_when": "Use this pattern when planning or reviewing code where before refactoring, pin current behavior with tests. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["then make it right", "then make", "it right", "refactoring", "successive refinement", "incremental change", "safe change", "refactoring serialdate", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-198 Then Make It Right\nTopic: Refactoring SerialDate\nAliases: then make it right, then make, it right, refactoring, successive refinement, incremental change, safe change, refactoring serialdate, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to then make it right: After behavior is safe, improve names, structure, and boundaries. Search terms that should match this issue include then make it right, then make, it right, refactoring, successive refinement.\nUse when: Use this pattern when planning or reviewing code where after behavior is safe, improve names, structure, and boundaries. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst nextBusinessDay = calendar.nextBusinessDay(date);\nGood Python:\nnext_business_day = calendar.next_business_day(date)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.\nLintability: low", "embedding_text": "Clean code pattern CC-198: Then Make It Right. Topic: Refactoring SerialDate. Rule family: refactoring. Aliases and smell terms: then make it right, then make, it right, refactoring, successive refinement, incremental change, safe change, refactoring serialdate, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to then make it right: After behavior is safe, improve names, structure, and boundaries. Search terms that should match this issue include then make it right, then make, it right, refactoring, successive refinement. Use when: Use this pattern when planning or reviewing code where after behavior is safe, improve names, structure, and boundaries. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use semantic search metadata first; automate only when the pattern has a low false-positive rate.. Good TypeScript example: const nextBusinessDay = calendar.nextBusinessDay(date); Good Python example: next_business_day = calendar.next_business_day(date) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "next_business_day = calendar.next_business_day(date)", "typescript": "const nextBusinessDay = calendar.nextBusinessDay(date);"}, "id": "CC-198", "lint_candidates": ["Use semantic search metadata first; automate only when the pattern has a low false-positive rate."], "lintability": "low", "problem": "Code has a clean-code risk related to then make it right: After behavior is safe, improve names, structure, and boundaries. Search terms that should match this issue include then make it right, then make, it right, refactoring, successive refinement.", "rule_family": "refactoring", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "Then Make It Right", "topic": "Refactoring SerialDate", "use_when": "Use this pattern when planning or reviewing code where after behavior is safe, improve names, structure, and boundaries. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["c1 inappropriate information", "inappropriate information", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-199 C1 Inappropriate Information\nTopic: Comments\nAliases: c1 inappropriate information, inappropriate information, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to c1 inappropriate information: Keep comments focused on local code, not unrelated project history. Search terms that should match this issue include c1 inappropriate information, inappropriate information, comment smell, stale comment, documentation noise.\nUse when: Use this pattern when planning or reviewing code where keep comments focused on local code, not unrelated project history. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nconst timeoutMs = settings.gatewayTimeoutMs;\nGood Python:\ntimeout_ms = settings.gateway_timeout_ms\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Keep comments focused on local code, not unrelated project history.\nLintability: low", "embedding_text": "Clean code pattern CC-199: C1 Inappropriate Information. Topic: Comments. Rule family: comments. Aliases and smell terms: c1 inappropriate information, inappropriate information, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to c1 inappropriate information: Keep comments focused on local code, not unrelated project history. Search terms that should match this issue include c1 inappropriate information, inappropriate information, comment smell, stale comment, documentation noise. Use when: Use this pattern when planning or reviewing code where keep comments focused on local code, not unrelated project history. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Keep comments focused on local code, not unrelated project history.. Good TypeScript example: const timeoutMs = settings.gatewayTimeoutMs; Good Python example: timeout_ms = settings.gateway_timeout_ms Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "timeout_ms = settings.gateway_timeout_ms", "typescript": "const timeoutMs = settings.gatewayTimeoutMs;"}, "id": "CC-199", "lint_candidates": ["Keep comments focused on local code, not unrelated project history."], "lintability": "low", "problem": "Code has a clean-code risk related to c1 inappropriate information: Keep comments focused on local code, not unrelated project history. Search terms that should match this issue include c1 inappropriate information, inappropriate information, comment smell, stale comment, documentation noise.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "C1 Inappropriate Information", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where keep comments focused on local code, not unrelated project history. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["c2 obsolete comment", "obsolete comment", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-200 C2 Obsolete Comment\nTopic: Comments\nAliases: c2 obsolete comment, obsolete comment, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to c2 obsolete comment: Delete comments that no longer match behavior. Search terms that should match this issue include c2 obsolete comment, obsolete comment, comment smell, stale comment, documentation noise.\nUse when: Use this pattern when planning or reviewing code where delete comments that no longer match behavior. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nconst retryDelay = retryPolicy.delayFor(attempt);\nGood Python:\nretry_delay = retry_policy.delay_for(attempt)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Delete comments that no longer match behavior.\nLintability: high", "embedding_text": "Clean code pattern CC-200: C2 Obsolete Comment. Topic: Comments. Rule family: comments. Aliases and smell terms: c2 obsolete comment, obsolete comment, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to c2 obsolete comment: Delete comments that no longer match behavior. Search terms that should match this issue include c2 obsolete comment, obsolete comment, comment smell, stale comment, documentation noise. Use when: Use this pattern when planning or reviewing code where delete comments that no longer match behavior. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Delete comments that no longer match behavior.. Good TypeScript example: const retryDelay = retryPolicy.delayFor(attempt); Good Python example: retry_delay = retry_policy.delay_for(attempt) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "retry_delay = retry_policy.delay_for(attempt)", "typescript": "const retryDelay = retryPolicy.delayFor(attempt);"}, "id": "CC-200", "lint_candidates": ["Delete comments that no longer match behavior."], "lintability": "high", "problem": "Code has a clean-code risk related to c2 obsolete comment: Delete comments that no longer match behavior. Search terms that should match this issue include c2 obsolete comment, obsolete comment, comment smell, stale comment, documentation noise.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "C2 Obsolete Comment", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where delete comments that no longer match behavior. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["c3 redundant comment", "redundant comment", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-201 C3 Redundant Comment\nTopic: Comments\nAliases: c3 redundant comment, redundant comment, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to c3 redundant comment: Remove comments that repeat the code. Search terms that should match this issue include c3 redundant comment, redundant comment, comment smell, stale comment, documentation noise.\nUse when: Use this pattern when planning or reviewing code where remove comments that repeat the code. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nreturn customer.isActive;\nGood Python:\nreturn customer.is_active\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Remove comments that repeat the code.\nLintability: low", "embedding_text": "Clean code pattern CC-201: C3 Redundant Comment. Topic: Comments. Rule family: comments. Aliases and smell terms: c3 redundant comment, redundant comment, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to c3 redundant comment: Remove comments that repeat the code. Search terms that should match this issue include c3 redundant comment, redundant comment, comment smell, stale comment, documentation noise. Use when: Use this pattern when planning or reviewing code where remove comments that repeat the code. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Remove comments that repeat the code.. Good TypeScript example: return customer.isActive; Good Python example: return customer.is_active Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "return customer.is_active", "typescript": "return customer.isActive;"}, "id": "CC-201", "lint_candidates": ["Remove comments that repeat the code."], "lintability": "low", "problem": "Code has a clean-code risk related to c3 redundant comment: Remove comments that repeat the code. Search terms that should match this issue include c3 redundant comment, redundant comment, comment smell, stale comment, documentation noise.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "C3 Redundant Comment", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where remove comments that repeat the code. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["c4 poorly written comment", "poorly written comment", "poorly written", "written comment", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# increments retry count\nretry_count += 1", "typescript": "// increments retry count\nretryCount += 1;"}, "display_text": "CC-202 C4 Poorly Written Comment\nTopic: Comments\nAliases: c4 poorly written comment, poorly written comment, poorly written, written comment, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to c4 poorly written comment: Rewrite or remove vague comments that do not explain a clear constraint. Search terms that should match this issue include c4 poorly written comment, poorly written comment, poorly written, written comment, comment smell.\nUse when: Use this pattern when planning or reviewing code where rewrite or remove vague comments that do not explain a clear constraint. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nconst normalizedSku = normalizeSku(sku);\nGood Python:\nnormalized_sku = normalize_sku(sku)\nBad TypeScript:\n// increments retry count\nretryCount += 1;\nBad Python:\n# increments retry count\nretry_count += 1\nLint candidates: Rewrite or remove vague comments that do not explain a clear constraint.\nLintability: low", "embedding_text": "Clean code pattern CC-202: C4 Poorly Written Comment. Topic: Comments. Rule family: comments. Aliases and smell terms: c4 poorly written comment, poorly written comment, poorly written, written comment, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to c4 poorly written comment: Rewrite or remove vague comments that do not explain a clear constraint. Search terms that should match this issue include c4 poorly written comment, poorly written comment, poorly written, written comment, comment smell. Use when: Use this pattern when planning or reviewing code where rewrite or remove vague comments that do not explain a clear constraint. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Rewrite or remove vague comments that do not explain a clear constraint.. Good TypeScript example: const normalizedSku = normalizeSku(sku); Good Python example: normalized_sku = normalize_sku(sku) Bad TypeScript example: // increments retry count\nretryCount += 1; Bad Python example: # increments retry count\nretry_count += 1", "good_examples": {"python": "normalized_sku = normalize_sku(sku)", "typescript": "const normalizedSku = normalizeSku(sku);"}, "id": "CC-202", "lint_candidates": ["Rewrite or remove vague comments that do not explain a clear constraint."], "lintability": "low", "problem": "Code has a clean-code risk related to c4 poorly written comment: Rewrite or remove vague comments that do not explain a clear constraint. Search terms that should match this issue include c4 poorly written comment, poorly written comment, poorly written, written comment, comment smell.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "C4 Poorly Written Comment", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where rewrite or remove vague comments that do not explain a clear constraint. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["c5 commented out code", "commented out code", "commented out", "out code", "comment smell", "stale comment", "documentation noise", "comment guidance", "comments", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.", "bad_examples": {"python": "# publish_receipt(receipt)\nsave_receipt(receipt)", "typescript": "// await publishReceipt(receipt);\nawait saveReceipt(receipt);"}, "display_text": "CC-203 C5 Commented Out Code\nTopic: Comments\nAliases: c5 commented out code, commented out code, commented out, out code, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to c5 commented out code: Delete commented code and rely on version history. Search terms that should match this issue include c5 commented out code, commented out code, commented out, out code, comment smell.\nUse when: Use this pattern when planning or reviewing code where delete commented code and rely on version history. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context.\nAvoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express.\nGood TypeScript:\nawait publishReceipt(receipt);\nGood Python:\npublish_receipt(receipt)\nBad TypeScript:\n// await publishReceipt(receipt);\nawait saveReceipt(receipt);\nBad Python:\n# publish_receipt(receipt)\nsave_receipt(receipt)\nLint candidates: Delete commented code and rely on version history.\nLintability: high", "embedding_text": "Clean code pattern CC-203: C5 Commented Out Code. Topic: Comments. Rule family: comments. Aliases and smell terms: c5 commented out code, commented out code, commented out, out code, comment smell, stale comment, documentation noise, comment guidance, comments, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to c5 commented out code: Delete commented code and rely on version history. Search terms that should match this issue include c5 commented out code, commented out code, commented out, out code, comment smell. Use when: Use this pattern when planning or reviewing code where delete commented code and rely on version history. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context. Avoid when: Avoid applying this mechanically when a short comment records an external constraint, legal requirement, or non-obvious tradeoff that code cannot express. Lint candidates: Delete commented code and rely on version history.. Good TypeScript example: await publishReceipt(receipt); Good Python example: publish_receipt(receipt) Bad TypeScript example: // await publishReceipt(receipt);\nawait saveReceipt(receipt); Bad Python example: # publish_receipt(receipt)\nsave_receipt(receipt)", "good_examples": {"python": "publish_receipt(receipt)", "typescript": "await publishReceipt(receipt);"}, "id": "CC-203", "lint_candidates": ["Delete commented code and rely on version history."], "lintability": "high", "problem": "Code has a clean-code risk related to c5 commented out code: Delete commented code and rely on version history. Search terms that should match this issue include c5 commented out code, commented out code, commented out, out code, comment smell.", "rule_family": "comments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "C5 Commented Out Code", "topic": "Comments", "use_when": "Use this pattern when planning or reviewing code where delete commented code and rely on version history. It is especially relevant when a comment is explaining confusing code, stale behavior, or nonlocal context."}
+{"aliases": ["e1 build requires more than one step", "build requires more than one step", "build requires", "one step", "environment", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-204 E1 Build Requires More Than One Step\nTopic: Environment\nAliases: e1 build requires more than one step, build requires more than one step, build requires, one step, environment, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to e1 build requires more than one step: Provide one command that builds the project reproducibly. Search terms that should match this issue include e1 build requires more than one step, build requires more than one step, build requires, one step, environment.\nUse when: Use this pattern when planning or reviewing code where provide one command that builds the project reproducibly. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nawait runCommand('npm run build');\nGood Python:\nrun_command('python -m build')\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Provide one command that builds the project reproducibly.\nLintability: high", "embedding_text": "Clean code pattern CC-204: E1 Build Requires More Than One Step. Topic: Environment. Rule family: clean_code. Aliases and smell terms: e1 build requires more than one step, build requires more than one step, build requires, one step, environment, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to e1 build requires more than one step: Provide one command that builds the project reproducibly. Search terms that should match this issue include e1 build requires more than one step, build requires more than one step, build requires, one step, environment. Use when: Use this pattern when planning or reviewing code where provide one command that builds the project reproducibly. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Provide one command that builds the project reproducibly.. Good TypeScript example: await runCommand('npm run build'); Good Python example: run_command('python -m build') Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "run_command('python -m build')", "typescript": "await runCommand('npm run build');"}, "id": "CC-204", "lint_candidates": ["Provide one command that builds the project reproducibly."], "lintability": "high", "problem": "Code has a clean-code risk related to e1 build requires more than one step: Provide one command that builds the project reproducibly. Search terms that should match this issue include e1 build requires more than one step, build requires more than one step, build requires, one step, environment.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "E1 Build Requires More Than One Step", "topic": "Environment", "use_when": "Use this pattern when planning or reviewing code where provide one command that builds the project reproducibly. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["e2 tests require more than one step", "tests require more than one step", "tests require", "one step", "unit test", "test smell", "test design", "test quality", "environment", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-205 E2 Tests Require More Than One Step\nTopic: Environment\nAliases: e2 tests require more than one step, tests require more than one step, tests require, one step, unit test, test smell, test design, test quality, environment, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to e2 tests require more than one step: Provide one command that runs the test suite reproducibly. Search terms that should match this issue include e2 tests require more than one step, tests require more than one step, tests require, one step, unit test.\nUse when: Use this pattern when planning or reviewing code where provide one command that runs the test suite reproducibly. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nawait runCommand('npm test');\nGood Python:\nrun_command('pytest')\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Provide one command that runs the test suite reproducibly.\nLintability: high", "embedding_text": "Clean code pattern CC-205: E2 Tests Require More Than One Step. Topic: Environment. Rule family: tests. Aliases and smell terms: e2 tests require more than one step, tests require more than one step, tests require, one step, unit test, test smell, test design, test quality, environment, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to e2 tests require more than one step: Provide one command that runs the test suite reproducibly. Search terms that should match this issue include e2 tests require more than one step, tests require more than one step, tests require, one step, unit test. Use when: Use this pattern when planning or reviewing code where provide one command that runs the test suite reproducibly. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Provide one command that runs the test suite reproducibly.. Good TypeScript example: await runCommand('npm test'); Good Python example: run_command('pytest') Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "run_command('pytest')", "typescript": "await runCommand('npm test');"}, "id": "CC-205", "lint_candidates": ["Provide one command that runs the test suite reproducibly."], "lintability": "high", "problem": "Code has a clean-code risk related to e2 tests require more than one step: Provide one command that runs the test suite reproducibly. Search terms that should match this issue include e2 tests require more than one step, tests require more than one step, tests require, one step, unit test.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "E2 Tests Require More Than One Step", "topic": "Environment", "use_when": "Use this pattern when planning or reviewing code where provide one command that runs the test suite reproducibly. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["f1 too many arguments", "too many arguments", "too many", "many arguments", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "create_delivery(order_id, starts_at, ends_at, timezone, carrier)", "typescript": "createDelivery(orderId, startsAt, endsAt, timezone, carrier);"}, "display_text": "CC-206 F1 Too Many Arguments\nTopic: Functions\nAliases: f1 too many arguments, too many arguments, too many, many arguments, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to f1 too many arguments: Group cohesive parameters or introduce a value object. Search terms that should match this issue include f1 too many arguments, too many arguments, too many, many arguments, function smell.\nUse when: Use this pattern when planning or reviewing code where group cohesive parameters or introduce a value object. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\ncreateDelivery(orderId, deliveryWindow);\nGood Python:\ncreate_delivery(order_id, delivery_window)\nBad TypeScript:\ncreateDelivery(orderId, startsAt, endsAt, timezone, carrier);\nBad Python:\ncreate_delivery(order_id, starts_at, ends_at, timezone, carrier)\nLint candidates: Group cohesive parameters or introduce a value object.\nLintability: high", "embedding_text": "Clean code pattern CC-206: F1 Too Many Arguments. Topic: Functions. Rule family: functions. Aliases and smell terms: f1 too many arguments, too many arguments, too many, many arguments, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to f1 too many arguments: Group cohesive parameters or introduce a value object. Search terms that should match this issue include f1 too many arguments, too many arguments, too many, many arguments, function smell. Use when: Use this pattern when planning or reviewing code where group cohesive parameters or introduce a value object. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Group cohesive parameters or introduce a value object.. Good TypeScript example: createDelivery(orderId, deliveryWindow); Good Python example: create_delivery(order_id, delivery_window) Bad TypeScript example: createDelivery(orderId, startsAt, endsAt, timezone, carrier); Bad Python example: create_delivery(order_id, starts_at, ends_at, timezone, carrier)", "good_examples": {"python": "create_delivery(order_id, delivery_window)", "typescript": "createDelivery(orderId, deliveryWindow);"}, "id": "CC-206", "lint_candidates": ["Group cohesive parameters or introduce a value object."], "lintability": "high", "problem": "Code has a clean-code risk related to f1 too many arguments: Group cohesive parameters or introduce a value object. Search terms that should match this issue include f1 too many arguments, too many arguments, too many, many arguments, function smell.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "F1 Too Many Arguments", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where group cohesive parameters or introduce a value object. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["f2 output arguments", "output arguments", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-207 F2 Output Arguments\nTopic: Functions\nAliases: f2 output arguments, output arguments, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to f2 output arguments: Return values instead of mutating output parameters. Search terms that should match this issue include f2 output arguments, output arguments, function smell, single responsibility, small function.\nUse when: Use this pattern when planning or reviewing code where return values instead of mutating output parameters. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nconst enriched = enrichOrder(order);\nGood Python:\nenriched = enrich_order(order)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Return values instead of mutating output parameters.\nLintability: high", "embedding_text": "Clean code pattern CC-207: F2 Output Arguments. Topic: Functions. Rule family: functions. Aliases and smell terms: f2 output arguments, output arguments, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to f2 output arguments: Return values instead of mutating output parameters. Search terms that should match this issue include f2 output arguments, output arguments, function smell, single responsibility, small function. Use when: Use this pattern when planning or reviewing code where return values instead of mutating output parameters. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Return values instead of mutating output parameters.. Good TypeScript example: const enriched = enrichOrder(order); Good Python example: enriched = enrich_order(order) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "enriched = enrich_order(order)", "typescript": "const enriched = enrichOrder(order);"}, "id": "CC-207", "lint_candidates": ["Return values instead of mutating output parameters."], "lintability": "high", "problem": "Code has a clean-code risk related to f2 output arguments: Return values instead of mutating output parameters. Search terms that should match this issue include f2 output arguments, output arguments, function smell, single responsibility, small function.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "F2 Output Arguments", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where return values instead of mutating output parameters. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["f3 flag arguments", "flag arguments", "function smell", "single responsibility", "small function", "function design", "flag argument", "boolean parameter", "selector argument", "boolean mode", "functions", "clean code"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "send_invoice(invoice, reminder=True)", "typescript": "sendInvoice(invoice, true);"}, "display_text": "CC-208 F3 Flag Arguments\nTopic: Functions\nAliases: f3 flag arguments, flag arguments, function smell, single responsibility, small function, function design, flag argument, boolean parameter, selector argument, boolean mode, functions, clean code\nProblem: Code has a clean-code risk related to f3 flag arguments: Replace boolean modes with named functions. Search terms that should match this issue include f3 flag arguments, flag arguments, function smell, single responsibility, small function.\nUse when: Use this pattern when planning or reviewing code where replace boolean modes with named functions. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nrenderCompactInvoice(invoice);\nGood Python:\nrender_compact_invoice(invoice)\nBad TypeScript:\nsendInvoice(invoice, true);\nBad Python:\nsend_invoice(invoice, reminder=True)\nLint candidates: Replace boolean modes with named functions.\nLintability: high", "embedding_text": "Clean code pattern CC-208: F3 Flag Arguments. Topic: Functions. Rule family: functions. Aliases and smell terms: f3 flag arguments, flag arguments, function smell, single responsibility, small function, function design, flag argument, boolean parameter, selector argument, boolean mode, functions, clean code. Problem: Code has a clean-code risk related to f3 flag arguments: Replace boolean modes with named functions. Search terms that should match this issue include f3 flag arguments, flag arguments, function smell, single responsibility, small function. Use when: Use this pattern when planning or reviewing code where replace boolean modes with named functions. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Replace boolean modes with named functions.. Good TypeScript example: renderCompactInvoice(invoice); Good Python example: render_compact_invoice(invoice) Bad TypeScript example: sendInvoice(invoice, true); Bad Python example: send_invoice(invoice, reminder=True)", "good_examples": {"python": "render_compact_invoice(invoice)", "typescript": "renderCompactInvoice(invoice);"}, "id": "CC-208", "lint_candidates": ["Replace boolean modes with named functions."], "lintability": "high", "problem": "Code has a clean-code risk related to f3 flag arguments: Replace boolean modes with named functions. Search terms that should match this issue include f3 flag arguments, flag arguments, function smell, single responsibility, small function.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "F3 Flag Arguments", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where replace boolean modes with named functions. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["f4 dead function", "dead function", "function smell", "single responsibility", "small function", "function design", "functions", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-209 F4 Dead Function\nTopic: Functions\nAliases: f4 dead function, dead function, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to f4 dead function: Remove unused functions instead of preserving them just in case. Search terms that should match this issue include f4 dead function, dead function, function smell, single responsibility, small function.\nUse when: Use this pattern when planning or reviewing code where remove unused functions instead of preserving them just in case. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nexport function activeFormatter(value: Money): string { return value.format(); }\nGood Python:\ndef active_formatter(value: Money) -> str:\n    return value.format()\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Remove unused functions instead of preserving them just in case.\nLintability: low", "embedding_text": "Clean code pattern CC-209: F4 Dead Function. Topic: Functions. Rule family: functions. Aliases and smell terms: f4 dead function, dead function, function smell, single responsibility, small function, function design, functions, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to f4 dead function: Remove unused functions instead of preserving them just in case. Search terms that should match this issue include f4 dead function, dead function, function smell, single responsibility, small function. Use when: Use this pattern when planning or reviewing code where remove unused functions instead of preserving them just in case. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Remove unused functions instead of preserving them just in case.. Good TypeScript example: export function activeFormatter(value: Money): string { return value.format(); } Good Python example: def active_formatter(value: Money) -> str:\n    return value.format() Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "def active_formatter(value: Money) -> str:\n    return value.format()", "typescript": "export function activeFormatter(value: Money): string { return value.format(); }"}, "id": "CC-209", "lint_candidates": ["Remove unused functions instead of preserving them just in case."], "lintability": "low", "problem": "Code has a clean-code risk related to f4 dead function: Remove unused functions instead of preserving them just in case. Search terms that should match this issue include f4 dead function, dead function, function smell, single responsibility, small function.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "F4 Dead Function", "topic": "Functions", "use_when": "Use this pattern when planning or reviewing code where remove unused functions instead of preserving them just in case. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["g1 multiple languages in one source file", "multiple languages in one source file", "multiple languages", "source file", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-210 G1 Multiple Languages In One Source File\nTopic: General\nAliases: g1 multiple languages in one source file, multiple languages in one source file, multiple languages, source file, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g1 multiple languages in one source file: Do not mix templates, SQL, and application code without boundaries. Search terms that should match this issue include g1 multiple languages in one source file, multiple languages in one source file, multiple languages, source file, general.\nUse when: Use this pattern when planning or reviewing code where do not mix templates, SQL, and application code without boundaries. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst query = ordersQuery.byCustomer(customerId);\nGood Python:\nquery = orders_query.by_customer(customer_id)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Do not mix templates, SQL, and application code without boundaries.\nLintability: low", "embedding_text": "Clean code pattern CC-210: G1 Multiple Languages In One Source File. Topic: General. Rule family: clean_code. Aliases and smell terms: g1 multiple languages in one source file, multiple languages in one source file, multiple languages, source file, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g1 multiple languages in one source file: Do not mix templates, SQL, and application code without boundaries. Search terms that should match this issue include g1 multiple languages in one source file, multiple languages in one source file, multiple languages, source file, general. Use when: Use this pattern when planning or reviewing code where do not mix templates, SQL, and application code without boundaries. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Do not mix templates, SQL, and application code without boundaries.. Good TypeScript example: const query = ordersQuery.byCustomer(customerId); Good Python example: query = orders_query.by_customer(customer_id) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "query = orders_query.by_customer(customer_id)", "typescript": "const query = ordersQuery.byCustomer(customerId);"}, "id": "CC-210", "lint_candidates": ["Do not mix templates, SQL, and application code without boundaries."], "lintability": "low", "problem": "Code has a clean-code risk related to g1 multiple languages in one source file: Do not mix templates, SQL, and application code without boundaries. Search terms that should match this issue include g1 multiple languages in one source file, multiple languages in one source file, multiple languages, source file, general.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G1 Multiple Languages In One Source File", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where do not mix templates, SQL, and application code without boundaries. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g2 obvious behavior unimplemented", "obvious behavior unimplemented", "obvious behavior", "behavior unimplemented", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-211 G2 Obvious Behavior Unimplemented\nTopic: General\nAliases: g2 obvious behavior unimplemented, obvious behavior unimplemented, obvious behavior, behavior unimplemented, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g2 obvious behavior unimplemented: Implement behavior implied by names and tests. Search terms that should match this issue include g2 obvious behavior unimplemented, obvious behavior unimplemented, obvious behavior, behavior unimplemented, general.\nUse when: Use this pattern when planning or reviewing code where implement behavior implied by names and tests. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nif (cart.isEmpty()) return EmptyCartTotal;\nGood Python:\nif cart.is_empty():\n    return EMPTY_CART_TOTAL\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Implement behavior implied by names and tests.\nLintability: low", "embedding_text": "Clean code pattern CC-211: G2 Obvious Behavior Unimplemented. Topic: General. Rule family: clean_code. Aliases and smell terms: g2 obvious behavior unimplemented, obvious behavior unimplemented, obvious behavior, behavior unimplemented, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g2 obvious behavior unimplemented: Implement behavior implied by names and tests. Search terms that should match this issue include g2 obvious behavior unimplemented, obvious behavior unimplemented, obvious behavior, behavior unimplemented, general. Use when: Use this pattern when planning or reviewing code where implement behavior implied by names and tests. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Implement behavior implied by names and tests.. Good TypeScript example: if (cart.isEmpty()) return EmptyCartTotal; Good Python example: if cart.is_empty():\n    return EMPTY_CART_TOTAL Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "if cart.is_empty():\n    return EMPTY_CART_TOTAL", "typescript": "if (cart.isEmpty()) return EmptyCartTotal;"}, "id": "CC-211", "lint_candidates": ["Implement behavior implied by names and tests."], "lintability": "low", "problem": "Code has a clean-code risk related to g2 obvious behavior unimplemented: Implement behavior implied by names and tests. Search terms that should match this issue include g2 obvious behavior unimplemented, obvious behavior unimplemented, obvious behavior, behavior unimplemented, general.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G2 Obvious Behavior Unimplemented", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where implement behavior implied by names and tests. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g3 incorrect boundary behavior", "incorrect boundary behavior", "incorrect boundary", "boundary behavior", "boundary design", "adapter", "third party code", "integration seam", "boundary condition", "edge case", "limit", "off by one"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-212 G3 Incorrect Boundary Behavior\nTopic: General\nAliases: g3 incorrect boundary behavior, incorrect boundary behavior, incorrect boundary, boundary behavior, boundary design, adapter, third party code, integration seam, boundary condition, edge case, limit, off by one\nProblem: Code has a clean-code risk related to g3 incorrect boundary behavior: Test and handle edges explicitly. Search terms that should match this issue include g3 incorrect boundary behavior, incorrect boundary behavior, incorrect boundary, boundary behavior, boundary design.\nUse when: Use this pattern when planning or reviewing code where test and handle edges explicitly. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nreturn clamp(discount, MIN_DISCOUNT, MAX_DISCOUNT);\nGood Python:\nreturn clamp(discount, MIN_DISCOUNT, MAX_DISCOUNT)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Test and handle edges explicitly.\nLintability: low", "embedding_text": "Clean code pattern CC-212: G3 Incorrect Boundary Behavior. Topic: General. Rule family: boundaries. Aliases and smell terms: g3 incorrect boundary behavior, incorrect boundary behavior, incorrect boundary, boundary behavior, boundary design, adapter, third party code, integration seam, boundary condition, edge case, limit, off by one. Problem: Code has a clean-code risk related to g3 incorrect boundary behavior: Test and handle edges explicitly. Search terms that should match this issue include g3 incorrect boundary behavior, incorrect boundary behavior, incorrect boundary, boundary behavior, boundary design. Use when: Use this pattern when planning or reviewing code where test and handle edges explicitly. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Test and handle edges explicitly.. Good TypeScript example: return clamp(discount, MIN_DISCOUNT, MAX_DISCOUNT); Good Python example: return clamp(discount, MIN_DISCOUNT, MAX_DISCOUNT) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "return clamp(discount, MIN_DISCOUNT, MAX_DISCOUNT)", "typescript": "return clamp(discount, MIN_DISCOUNT, MAX_DISCOUNT);"}, "id": "CC-212", "lint_candidates": ["Test and handle edges explicitly."], "lintability": "low", "problem": "Code has a clean-code risk related to g3 incorrect boundary behavior: Test and handle edges explicitly. Search terms that should match this issue include g3 incorrect boundary behavior, incorrect boundary behavior, incorrect boundary, boundary behavior, boundary design.", "rule_family": "boundaries", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G3 Incorrect Boundary Behavior", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where test and handle edges explicitly. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g4 overridden safeties", "overridden safeties", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-213 G4 Overridden Safeties\nTopic: General\nAliases: g4 overridden safeties, overridden safeties, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g4 overridden safeties: Do not suppress type, lint, or runtime safety without a local reason. Search terms that should match this issue include g4 overridden safeties, overridden safeties, general, clean code, code smell.\nUse when: Use this pattern when planning or reviewing code where do not suppress type, lint, or runtime safety without a local reason. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst amount = Money.parse(input.amount);\nGood Python:\namount = Money.parse(payload['amount'])\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Do not suppress type, lint, or runtime safety without a local reason.\nLintability: low", "embedding_text": "Clean code pattern CC-213: G4 Overridden Safeties. Topic: General. Rule family: clean_code. Aliases and smell terms: g4 overridden safeties, overridden safeties, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g4 overridden safeties: Do not suppress type, lint, or runtime safety without a local reason. Search terms that should match this issue include g4 overridden safeties, overridden safeties, general, clean code, code smell. Use when: Use this pattern when planning or reviewing code where do not suppress type, lint, or runtime safety without a local reason. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Do not suppress type, lint, or runtime safety without a local reason.. Good TypeScript example: const amount = Money.parse(input.amount); Good Python example: amount = Money.parse(payload['amount']) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "amount = Money.parse(payload['amount'])", "typescript": "const amount = Money.parse(input.amount);"}, "id": "CC-213", "lint_candidates": ["Do not suppress type, lint, or runtime safety without a local reason."], "lintability": "low", "problem": "Code has a clean-code risk related to g4 overridden safeties: Do not suppress type, lint, or runtime safety without a local reason. Search terms that should match this issue include g4 overridden safeties, overridden safeties, general, clean code, code smell.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G4 Overridden Safeties", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where do not suppress type, lint, or runtime safety without a local reason. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g5 duplication", "duplication", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-214 G5 Duplication\nTopic: General\nAliases: g5 duplication, duplication, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g5 duplication: Remove repeated knowledge behind one named abstraction. Search terms that should match this issue include g5 duplication, duplication, general, clean code, code smell.\nUse when: Use this pattern when planning or reviewing code where remove repeated knowledge behind one named abstraction. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nreturn feePolicy.calculate(amount);\nGood Python:\nreturn fee_policy.calculate(amount)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Remove repeated knowledge behind one named abstraction.\nLintability: low", "embedding_text": "Clean code pattern CC-214: G5 Duplication. Topic: General. Rule family: clean_code. Aliases and smell terms: g5 duplication, duplication, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g5 duplication: Remove repeated knowledge behind one named abstraction. Search terms that should match this issue include g5 duplication, duplication, general, clean code, code smell. Use when: Use this pattern when planning or reviewing code where remove repeated knowledge behind one named abstraction. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Remove repeated knowledge behind one named abstraction.. Good TypeScript example: return feePolicy.calculate(amount); Good Python example: return fee_policy.calculate(amount) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "return fee_policy.calculate(amount)", "typescript": "return feePolicy.calculate(amount);"}, "id": "CC-214", "lint_candidates": ["Remove repeated knowledge behind one named abstraction."], "lintability": "low", "problem": "Code has a clean-code risk related to g5 duplication: Remove repeated knowledge behind one named abstraction. Search terms that should match this issue include g5 duplication, duplication, general, clean code, code smell.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G5 Duplication", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where remove repeated knowledge behind one named abstraction. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g6 wrong abstraction level", "wrong abstraction level", "wrong abstraction", "abstraction level", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-215 G6 Wrong Abstraction Level\nTopic: General\nAliases: g6 wrong abstraction level, wrong abstraction level, wrong abstraction, abstraction level, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g6 wrong abstraction level: Do not mix policy with low-level mechanics. Search terms that should match this issue include g6 wrong abstraction level, wrong abstraction level, wrong abstraction, abstraction level, general.\nUse when: Use this pattern when planning or reviewing code where do not mix policy with low-level mechanics. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nreturn renewalPolicy.canRenew(subscription, now);\nGood Python:\nreturn renewal_policy.can_renew(subscription, now)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Do not mix policy with low-level mechanics.\nLintability: low", "embedding_text": "Clean code pattern CC-215: G6 Wrong Abstraction Level. Topic: General. Rule family: clean_code. Aliases and smell terms: g6 wrong abstraction level, wrong abstraction level, wrong abstraction, abstraction level, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g6 wrong abstraction level: Do not mix policy with low-level mechanics. Search terms that should match this issue include g6 wrong abstraction level, wrong abstraction level, wrong abstraction, abstraction level, general. Use when: Use this pattern when planning or reviewing code where do not mix policy with low-level mechanics. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Do not mix policy with low-level mechanics.. Good TypeScript example: return renewalPolicy.canRenew(subscription, now); Good Python example: return renewal_policy.can_renew(subscription, now) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "return renewal_policy.can_renew(subscription, now)", "typescript": "return renewalPolicy.canRenew(subscription, now);"}, "id": "CC-215", "lint_candidates": ["Do not mix policy with low-level mechanics."], "lintability": "low", "problem": "Code has a clean-code risk related to g6 wrong abstraction level: Do not mix policy with low-level mechanics. Search terms that should match this issue include g6 wrong abstraction level, wrong abstraction level, wrong abstraction, abstraction level, general.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G6 Wrong Abstraction Level", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where do not mix policy with low-level mechanics. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g7 base depends on derivative", "base depends on derivative", "base depends", "on derivative", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-216 G7 Base Depends On Derivative\nTopic: General\nAliases: g7 base depends on derivative, base depends on derivative, base depends, on derivative, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g7 base depends on derivative: Keep base abstractions independent from specific implementations. Search terms that should match this issue include g7 base depends on derivative, base depends on derivative, base depends, on derivative, general.\nUse when: Use this pattern when planning or reviewing code where keep base abstractions independent from specific implementations. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\ninterface Storage { save(record: Record): Promise<void>; }\nGood Python:\nclass Storage(Protocol):\n    def save(self, record: Record) -> None: ...\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Keep base abstractions independent from specific implementations.\nLintability: low", "embedding_text": "Clean code pattern CC-216: G7 Base Depends On Derivative. Topic: General. Rule family: clean_code. Aliases and smell terms: g7 base depends on derivative, base depends on derivative, base depends, on derivative, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g7 base depends on derivative: Keep base abstractions independent from specific implementations. Search terms that should match this issue include g7 base depends on derivative, base depends on derivative, base depends, on derivative, general. Use when: Use this pattern when planning or reviewing code where keep base abstractions independent from specific implementations. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Keep base abstractions independent from specific implementations.. Good TypeScript example: interface Storage { save(record: Record): Promise<void>; } Good Python example: class Storage(Protocol):\n    def save(self, record: Record) -> None: ... Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "class Storage(Protocol):\n    def save(self, record: Record) -> None: ...", "typescript": "interface Storage { save(record: Record): Promise<void>; }"}, "id": "CC-216", "lint_candidates": ["Keep base abstractions independent from specific implementations."], "lintability": "low", "problem": "Code has a clean-code risk related to g7 base depends on derivative: Keep base abstractions independent from specific implementations. Search terms that should match this issue include g7 base depends on derivative, base depends on derivative, base depends, on derivative, general.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G7 Base Depends On Derivative", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where keep base abstractions independent from specific implementations. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g8 too much information", "too much information", "too much", "much information", "formatting", "layout", "readability", "code style", "general", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-217 G8 Too Much Information\nTopic: General\nAliases: g8 too much information, too much information, too much, much information, formatting, layout, readability, code style, general, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to g8 too much information: Expose the smallest useful public API. Search terms that should match this issue include g8 too much information, too much information, too much, much information, formatting.\nUse when: Use this pattern when planning or reviewing code where expose the smallest useful public API. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\norder.cancel(reason);\nGood Python:\norder.cancel(reason)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Expose the smallest useful public API.\nLintability: low", "embedding_text": "Clean code pattern CC-217: G8 Too Much Information. Topic: General. Rule family: formatting. Aliases and smell terms: g8 too much information, too much information, too much, much information, formatting, layout, readability, code style, general, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to g8 too much information: Expose the smallest useful public API. Search terms that should match this issue include g8 too much information, too much information, too much, much information, formatting. Use when: Use this pattern when planning or reviewing code where expose the smallest useful public API. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Expose the smallest useful public API.. Good TypeScript example: order.cancel(reason); Good Python example: order.cancel(reason) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "order.cancel(reason)", "typescript": "order.cancel(reason);"}, "id": "CC-217", "lint_candidates": ["Expose the smallest useful public API."], "lintability": "low", "problem": "Code has a clean-code risk related to g8 too much information: Expose the smallest useful public API. Search terms that should match this issue include g8 too much information, too much information, too much, much information, formatting.", "rule_family": "formatting", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G8 Too Much Information", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where expose the smallest useful public API. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g9 dead code", "dead code", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-218 G9 Dead Code\nTopic: General\nAliases: g9 dead code, dead code, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g9 dead code: Remove unreachable or unused code. Search terms that should match this issue include g9 dead code, dead code, general, clean code, code smell.\nUse when: Use this pattern when planning or reviewing code where remove unreachable or unused code. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nreturn activeRules.filter(rule => rule.applies(order));\nGood Python:\nreturn [rule for rule in active_rules if rule.applies(order)]\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Remove unreachable or unused code.\nLintability: high", "embedding_text": "Clean code pattern CC-218: G9 Dead Code. Topic: General. Rule family: clean_code. Aliases and smell terms: g9 dead code, dead code, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g9 dead code: Remove unreachable or unused code. Search terms that should match this issue include g9 dead code, dead code, general, clean code, code smell. Use when: Use this pattern when planning or reviewing code where remove unreachable or unused code. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Remove unreachable or unused code.. Good TypeScript example: return activeRules.filter(rule => rule.applies(order)); Good Python example: return [rule for rule in active_rules if rule.applies(order)] Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "return [rule for rule in active_rules if rule.applies(order)]", "typescript": "return activeRules.filter(rule => rule.applies(order));"}, "id": "CC-218", "lint_candidates": ["Remove unreachable or unused code."], "lintability": "high", "problem": "Code has a clean-code risk related to g9 dead code: Remove unreachable or unused code. Search terms that should match this issue include g9 dead code, dead code, general, clean code, code smell.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G9 Dead Code", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where remove unreachable or unused code. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g10 vertical separation", "vertical separation", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-219 G10 Vertical Separation\nTopic: General\nAliases: g10 vertical separation, vertical separation, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g10 vertical separation: Keep related concepts near each other. Search terms that should match this issue include g10 vertical separation, vertical separation, general, clean code, code smell.\nUse when: Use this pattern when planning or reviewing code where keep related concepts near each other. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst tax = calculateTax(order);\nconst total = order.subtotal.plus(tax);\nGood Python:\ntax = calculate_tax(order)\ntotal = order.subtotal + tax\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Keep related concepts near each other.\nLintability: low", "embedding_text": "Clean code pattern CC-219: G10 Vertical Separation. Topic: General. Rule family: clean_code. Aliases and smell terms: g10 vertical separation, vertical separation, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g10 vertical separation: Keep related concepts near each other. Search terms that should match this issue include g10 vertical separation, vertical separation, general, clean code, code smell. Use when: Use this pattern when planning or reviewing code where keep related concepts near each other. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Keep related concepts near each other.. Good TypeScript example: const tax = calculateTax(order);\nconst total = order.subtotal.plus(tax); Good Python example: tax = calculate_tax(order)\ntotal = order.subtotal + tax Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "tax = calculate_tax(order)\ntotal = order.subtotal + tax", "typescript": "const tax = calculateTax(order);\nconst total = order.subtotal.plus(tax);"}, "id": "CC-219", "lint_candidates": ["Keep related concepts near each other."], "lintability": "low", "problem": "Code has a clean-code risk related to g10 vertical separation: Keep related concepts near each other. Search terms that should match this issue include g10 vertical separation, vertical separation, general, clean code, code smell.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G10 Vertical Separation", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where keep related concepts near each other. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g11 inconsistency", "inconsistency", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-220 G11 Inconsistency\nTopic: General\nAliases: g11 inconsistency, inconsistency, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g11 inconsistency: Use the same style for the same idea. Search terms that should match this issue include g11 inconsistency, inconsistency, general, clean code, code smell.\nUse when: Use this pattern when planning or reviewing code where use the same style for the same idea. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nfetchCustomer(customerId);\nGood Python:\nfetch_customer(customer_id)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use the same style for the same idea.\nLintability: low", "embedding_text": "Clean code pattern CC-220: G11 Inconsistency. Topic: General. Rule family: clean_code. Aliases and smell terms: g11 inconsistency, inconsistency, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g11 inconsistency: Use the same style for the same idea. Search terms that should match this issue include g11 inconsistency, inconsistency, general, clean code, code smell. Use when: Use this pattern when planning or reviewing code where use the same style for the same idea. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use the same style for the same idea.. Good TypeScript example: fetchCustomer(customerId); Good Python example: fetch_customer(customer_id) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "fetch_customer(customer_id)", "typescript": "fetchCustomer(customerId);"}, "id": "CC-220", "lint_candidates": ["Use the same style for the same idea."], "lintability": "low", "problem": "Code has a clean-code risk related to g11 inconsistency: Use the same style for the same idea. Search terms that should match this issue include g11 inconsistency, inconsistency, general, clean code, code smell.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G11 Inconsistency", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where use the same style for the same idea. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g12 clutter", "clutter", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-221 G12 Clutter\nTopic: General\nAliases: g12 clutter, clutter, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g12 clutter: Remove unused variables, empty constructors, and redundant wrappers. Search terms that should match this issue include g12 clutter, clutter, general, clean code, code smell.\nUse when: Use this pattern when planning or reviewing code where remove unused variables, empty constructors, and redundant wrappers. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nreturn normalizeEmail(email);\nGood Python:\nreturn normalize_email(email)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Remove unused variables, empty constructors, and redundant wrappers.\nLintability: low", "embedding_text": "Clean code pattern CC-221: G12 Clutter. Topic: General. Rule family: clean_code. Aliases and smell terms: g12 clutter, clutter, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g12 clutter: Remove unused variables, empty constructors, and redundant wrappers. Search terms that should match this issue include g12 clutter, clutter, general, clean code, code smell. Use when: Use this pattern when planning or reviewing code where remove unused variables, empty constructors, and redundant wrappers. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Remove unused variables, empty constructors, and redundant wrappers.. Good TypeScript example: return normalizeEmail(email); Good Python example: return normalize_email(email) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "return normalize_email(email)", "typescript": "return normalizeEmail(email);"}, "id": "CC-221", "lint_candidates": ["Remove unused variables, empty constructors, and redundant wrappers."], "lintability": "low", "problem": "Code has a clean-code risk related to g12 clutter: Remove unused variables, empty constructors, and redundant wrappers. Search terms that should match this issue include g12 clutter, clutter, general, clean code, code smell.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G12 Clutter", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where remove unused variables, empty constructors, and redundant wrappers. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g13 artificial coupling", "artificial coupling", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-222 G13 Artificial Coupling\nTopic: General\nAliases: g13 artificial coupling, artificial coupling, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g13 artificial coupling: Do not make unrelated modules depend on each other for convenience. Search terms that should match this issue include g13 artificial coupling, artificial coupling, general, clean code, code smell.\nUse when: Use this pattern when planning or reviewing code where do not make unrelated modules depend on each other for convenience. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\ntaxCalculator.calculate(order);\nGood Python:\ntax_calculator.calculate(order)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Do not make unrelated modules depend on each other for convenience.\nLintability: low", "embedding_text": "Clean code pattern CC-222: G13 Artificial Coupling. Topic: General. Rule family: clean_code. Aliases and smell terms: g13 artificial coupling, artificial coupling, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g13 artificial coupling: Do not make unrelated modules depend on each other for convenience. Search terms that should match this issue include g13 artificial coupling, artificial coupling, general, clean code, code smell. Use when: Use this pattern when planning or reviewing code where do not make unrelated modules depend on each other for convenience. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Do not make unrelated modules depend on each other for convenience.. Good TypeScript example: taxCalculator.calculate(order); Good Python example: tax_calculator.calculate(order) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "tax_calculator.calculate(order)", "typescript": "taxCalculator.calculate(order);"}, "id": "CC-222", "lint_candidates": ["Do not make unrelated modules depend on each other for convenience."], "lintability": "low", "problem": "Code has a clean-code risk related to g13 artificial coupling: Do not make unrelated modules depend on each other for convenience. Search terms that should match this issue include g13 artificial coupling, artificial coupling, general, clean code, code smell.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G13 Artificial Coupling", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where do not make unrelated modules depend on each other for convenience. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g14 feature envy", "feature envy", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-223 G14 Feature Envy\nTopic: General\nAliases: g14 feature envy, feature envy, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g14 feature envy: Move behavior close to the data it uses most. Search terms that should match this issue include g14 feature envy, feature envy, general, clean code, code smell.\nUse when: Use this pattern when planning or reviewing code where move behavior close to the data it uses most. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\norder.total();\nGood Python:\norder.total()\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Move behavior close to the data it uses most.\nLintability: low", "embedding_text": "Clean code pattern CC-223: G14 Feature Envy. Topic: General. Rule family: clean_code. Aliases and smell terms: g14 feature envy, feature envy, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g14 feature envy: Move behavior close to the data it uses most. Search terms that should match this issue include g14 feature envy, feature envy, general, clean code, code smell. Use when: Use this pattern when planning or reviewing code where move behavior close to the data it uses most. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Move behavior close to the data it uses most.. Good TypeScript example: order.total(); Good Python example: order.total() Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "order.total()", "typescript": "order.total();"}, "id": "CC-223", "lint_candidates": ["Move behavior close to the data it uses most."], "lintability": "low", "problem": "Code has a clean-code risk related to g14 feature envy: Move behavior close to the data it uses most. Search terms that should match this issue include g14 feature envy, feature envy, general, clean code, code smell.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G14 Feature Envy", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where move behavior close to the data it uses most. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g15 selector arguments", "selector arguments", "argument smell", "parameter smell", "call site clarity", "function signature", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid wrapping parameters when the existing call is already clear and the values do not form a stable concept.", "bad_examples": {"python": "send_invoice(invoice, reminder=True)", "typescript": "sendInvoice(invoice, true);"}, "display_text": "CC-224 G15 Selector Arguments\nTopic: General\nAliases: g15 selector arguments, selector arguments, argument smell, parameter smell, call site clarity, function signature, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g15 selector arguments: Replace selector parameters with polymorphism or named operations. Search terms that should match this issue include g15 selector arguments, selector arguments, argument smell, parameter smell, call site clarity.\nUse when: Use this pattern when planning or reviewing code where replace selector parameters with polymorphism or named operations. It is especially relevant when a call site is unclear or a parameter changes behavior by mode.\nAvoid when: Avoid wrapping parameters when the existing call is already clear and the values do not form a stable concept.\nGood TypeScript:\nexportCsv(report);\nGood Python:\nexport_csv(report)\nBad TypeScript:\nsendInvoice(invoice, true);\nBad Python:\nsend_invoice(invoice, reminder=True)\nLint candidates: Replace selector parameters with polymorphism or named operations.\nLintability: low", "embedding_text": "Clean code pattern CC-224: G15 Selector Arguments. Topic: General. Rule family: function_arguments. Aliases and smell terms: g15 selector arguments, selector arguments, argument smell, parameter smell, call site clarity, function signature, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g15 selector arguments: Replace selector parameters with polymorphism or named operations. Search terms that should match this issue include g15 selector arguments, selector arguments, argument smell, parameter smell, call site clarity. Use when: Use this pattern when planning or reviewing code where replace selector parameters with polymorphism or named operations. It is especially relevant when a call site is unclear or a parameter changes behavior by mode. Avoid when: Avoid wrapping parameters when the existing call is already clear and the values do not form a stable concept. Lint candidates: Replace selector parameters with polymorphism or named operations.. Good TypeScript example: exportCsv(report); Good Python example: export_csv(report) Bad TypeScript example: sendInvoice(invoice, true); Bad Python example: send_invoice(invoice, reminder=True)", "good_examples": {"python": "export_csv(report)", "typescript": "exportCsv(report);"}, "id": "CC-224", "lint_candidates": ["Replace selector parameters with polymorphism or named operations."], "lintability": "low", "problem": "Code has a clean-code risk related to g15 selector arguments: Replace selector parameters with polymorphism or named operations. Search terms that should match this issue include g15 selector arguments, selector arguments, argument smell, parameter smell, call site clarity.", "rule_family": "function_arguments", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G15 Selector Arguments", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where replace selector parameters with polymorphism or named operations. It is especially relevant when a call site is unclear or a parameter changes behavior by mode."}
+{"aliases": ["g16 obscured intent", "obscured intent", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-225 G16 Obscured Intent\nTopic: General\nAliases: g16 obscured intent, obscured intent, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g16 obscured intent: Name intermediate concepts in dense logic. Search terms that should match this issue include g16 obscured intent, obscured intent, general, clean code, code smell.\nUse when: Use this pattern when planning or reviewing code where name intermediate concepts in dense logic. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst canRefund = order.isPaid && withinRefundWindow(order, now);\nGood Python:\ncan_refund = order.is_paid and within_refund_window(order, now)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Name intermediate concepts in dense logic.\nLintability: low", "embedding_text": "Clean code pattern CC-225: G16 Obscured Intent. Topic: General. Rule family: clean_code. Aliases and smell terms: g16 obscured intent, obscured intent, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g16 obscured intent: Name intermediate concepts in dense logic. Search terms that should match this issue include g16 obscured intent, obscured intent, general, clean code, code smell. Use when: Use this pattern when planning or reviewing code where name intermediate concepts in dense logic. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Name intermediate concepts in dense logic.. Good TypeScript example: const canRefund = order.isPaid && withinRefundWindow(order, now); Good Python example: can_refund = order.is_paid and within_refund_window(order, now) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "can_refund = order.is_paid and within_refund_window(order, now)", "typescript": "const canRefund = order.isPaid && withinRefundWindow(order, now);"}, "id": "CC-225", "lint_candidates": ["Name intermediate concepts in dense logic."], "lintability": "low", "problem": "Code has a clean-code risk related to g16 obscured intent: Name intermediate concepts in dense logic. Search terms that should match this issue include g16 obscured intent, obscured intent, general, clean code, code smell.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G16 Obscured Intent", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where name intermediate concepts in dense logic. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g17 misplaced responsibility", "misplaced responsibility", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-226 G17 Misplaced Responsibility\nTopic: General\nAliases: g17 misplaced responsibility, misplaced responsibility, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g17 misplaced responsibility: Put behavior in the module that owns the concept. Search terms that should match this issue include g17 misplaced responsibility, misplaced responsibility, general, clean code, code smell.\nUse when: Use this pattern when planning or reviewing code where put behavior in the module that owns the concept. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\ninvoice.markPaid(payment);\nGood Python:\ninvoice.mark_paid(payment)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Put behavior in the module that owns the concept.\nLintability: low", "embedding_text": "Clean code pattern CC-226: G17 Misplaced Responsibility. Topic: General. Rule family: clean_code. Aliases and smell terms: g17 misplaced responsibility, misplaced responsibility, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g17 misplaced responsibility: Put behavior in the module that owns the concept. Search terms that should match this issue include g17 misplaced responsibility, misplaced responsibility, general, clean code, code smell. Use when: Use this pattern when planning or reviewing code where put behavior in the module that owns the concept. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Put behavior in the module that owns the concept.. Good TypeScript example: invoice.markPaid(payment); Good Python example: invoice.mark_paid(payment) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "invoice.mark_paid(payment)", "typescript": "invoice.markPaid(payment);"}, "id": "CC-226", "lint_candidates": ["Put behavior in the module that owns the concept."], "lintability": "low", "problem": "Code has a clean-code risk related to g17 misplaced responsibility: Put behavior in the module that owns the concept. Search terms that should match this issue include g17 misplaced responsibility, misplaced responsibility, general, clean code, code smell.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G17 Misplaced Responsibility", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where put behavior in the module that owns the concept. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g18 inappropriate static", "inappropriate static", "static state", "global state", "hidden dependency", "test isolation", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-227 G18 Inappropriate Static\nTopic: General\nAliases: g18 inappropriate static, inappropriate static, static state, global state, hidden dependency, test isolation, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g18 inappropriate static: Avoid static/global state for behavior that needs dependencies or tests. Search terms that should match this issue include g18 inappropriate static, inappropriate static, static state, global state, hidden dependency.\nUse when: Use this pattern when planning or reviewing code where avoid static/global state for behavior that needs dependencies or tests. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nnew ExchangeRateService(rateProvider).convert(amount, currency);\nGood Python:\nExchangeRateService(rate_provider).convert(amount, currency)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Avoid static/global state for behavior that needs dependencies or tests.\nLintability: low", "embedding_text": "Clean code pattern CC-227: G18 Inappropriate Static. Topic: General. Rule family: clean_code. Aliases and smell terms: g18 inappropriate static, inappropriate static, static state, global state, hidden dependency, test isolation, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g18 inappropriate static: Avoid static/global state for behavior that needs dependencies or tests. Search terms that should match this issue include g18 inappropriate static, inappropriate static, static state, global state, hidden dependency. Use when: Use this pattern when planning or reviewing code where avoid static/global state for behavior that needs dependencies or tests. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Avoid static/global state for behavior that needs dependencies or tests.. Good TypeScript example: new ExchangeRateService(rateProvider).convert(amount, currency); Good Python example: ExchangeRateService(rate_provider).convert(amount, currency) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "ExchangeRateService(rate_provider).convert(amount, currency)", "typescript": "new ExchangeRateService(rateProvider).convert(amount, currency);"}, "id": "CC-227", "lint_candidates": ["Avoid static/global state for behavior that needs dependencies or tests."], "lintability": "low", "problem": "Code has a clean-code risk related to g18 inappropriate static: Avoid static/global state for behavior that needs dependencies or tests. Search terms that should match this issue include g18 inappropriate static, inappropriate static, static state, global state, hidden dependency.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G18 Inappropriate Static", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where avoid static/global state for behavior that needs dependencies or tests. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g19 explanatory variables", "explanatory variables", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-228 G19 Explanatory Variables\nTopic: General\nAliases: g19 explanatory variables, explanatory variables, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g19 explanatory variables: Use local names to explain subexpressions. Search terms that should match this issue include g19 explanatory variables, explanatory variables, general, clean code, code smell.\nUse when: Use this pattern when planning or reviewing code where use local names to explain subexpressions. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst isRenewalDue = subscription.expiresAt <= now;\nGood Python:\nis_renewal_due = subscription.expires_at <= now\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use local names to explain subexpressions.\nLintability: low", "embedding_text": "Clean code pattern CC-228: G19 Explanatory Variables. Topic: General. Rule family: clean_code. Aliases and smell terms: g19 explanatory variables, explanatory variables, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g19 explanatory variables: Use local names to explain subexpressions. Search terms that should match this issue include g19 explanatory variables, explanatory variables, general, clean code, code smell. Use when: Use this pattern when planning or reviewing code where use local names to explain subexpressions. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use local names to explain subexpressions.. Good TypeScript example: const isRenewalDue = subscription.expiresAt <= now; Good Python example: is_renewal_due = subscription.expires_at <= now Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "is_renewal_due = subscription.expires_at <= now", "typescript": "const isRenewalDue = subscription.expiresAt <= now;"}, "id": "CC-228", "lint_candidates": ["Use local names to explain subexpressions."], "lintability": "low", "problem": "Code has a clean-code risk related to g19 explanatory variables: Use local names to explain subexpressions. Search terms that should match this issue include g19 explanatory variables, explanatory variables, general, clean code, code smell.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G19 Explanatory Variables", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where use local names to explain subexpressions. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g20 function names say what they do", "function names say what they do", "function names", "they do", "naming smell", "identifier name", "semantic naming", "readable name", "general", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-229 G20 Function Names Say What They Do\nTopic: General\nAliases: g20 function names say what they do, function names say what they do, function names, they do, naming smell, identifier name, semantic naming, readable name, general, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to g20 function names say what they do: Rename vague functions to describe their actual effect. Search terms that should match this issue include g20 function names say what they do, function names say what they do, function names, they do, naming smell.\nUse when: Use this pattern when planning or reviewing code where rename vague functions to describe their actual effect. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\narchiveExpiredSessions();\nGood Python:\narchive_expired_sessions()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Rename vague functions to describe their actual effect.\nLintability: low", "embedding_text": "Clean code pattern CC-229: G20 Function Names Say What They Do. Topic: General. Rule family: naming. Aliases and smell terms: g20 function names say what they do, function names say what they do, function names, they do, naming smell, identifier name, semantic naming, readable name, general, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to g20 function names say what they do: Rename vague functions to describe their actual effect. Search terms that should match this issue include g20 function names say what they do, function names say what they do, function names, they do, naming smell. Use when: Use this pattern when planning or reviewing code where rename vague functions to describe their actual effect. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Rename vague functions to describe their actual effect.. Good TypeScript example: archiveExpiredSessions(); Good Python example: archive_expired_sessions() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "archive_expired_sessions()", "typescript": "archiveExpiredSessions();"}, "id": "CC-229", "lint_candidates": ["Rename vague functions to describe their actual effect."], "lintability": "low", "problem": "Code has a clean-code risk related to g20 function names say what they do: Rename vague functions to describe their actual effect. Search terms that should match this issue include g20 function names say what they do, function names say what they do, function names, they do, naming smell.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G20 Function Names Say What They Do", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where rename vague functions to describe their actual effect. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["g21 understand the algorithm", "understand the algorithm", "understand the", "the algorithm", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-230 G21 Understand The Algorithm\nTopic: General\nAliases: g21 understand the algorithm, understand the algorithm, understand the, the algorithm, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g21 understand the algorithm: Refactor only after you can explain the algorithm with tests. Search terms that should match this issue include g21 understand the algorithm, understand the algorithm, understand the, the algorithm, general.\nUse when: Use this pattern when planning or reviewing code where refactor only after you can explain the algorithm with tests. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst allocation = allocatePaymentsOldestFirst(payments, invoices);\nGood Python:\nallocation = allocate_payments_oldest_first(payments, invoices)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Refactor only after you can explain the algorithm with tests.\nLintability: low", "embedding_text": "Clean code pattern CC-230: G21 Understand The Algorithm. Topic: General. Rule family: clean_code. Aliases and smell terms: g21 understand the algorithm, understand the algorithm, understand the, the algorithm, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g21 understand the algorithm: Refactor only after you can explain the algorithm with tests. Search terms that should match this issue include g21 understand the algorithm, understand the algorithm, understand the, the algorithm, general. Use when: Use this pattern when planning or reviewing code where refactor only after you can explain the algorithm with tests. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Refactor only after you can explain the algorithm with tests.. Good TypeScript example: const allocation = allocatePaymentsOldestFirst(payments, invoices); Good Python example: allocation = allocate_payments_oldest_first(payments, invoices) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "allocation = allocate_payments_oldest_first(payments, invoices)", "typescript": "const allocation = allocatePaymentsOldestFirst(payments, invoices);"}, "id": "CC-230", "lint_candidates": ["Refactor only after you can explain the algorithm with tests."], "lintability": "low", "problem": "Code has a clean-code risk related to g21 understand the algorithm: Refactor only after you can explain the algorithm with tests. Search terms that should match this issue include g21 understand the algorithm, understand the algorithm, understand the, the algorithm, general.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G21 Understand The Algorithm", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where refactor only after you can explain the algorithm with tests. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g22 make logical dependencies physical", "make logical dependencies physical", "make logical", "dependencies physical", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-231 G22 Make Logical Dependencies Physical\nTopic: General\nAliases: g22 make logical dependencies physical, make logical dependencies physical, make logical, dependencies physical, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g22 make logical dependencies physical: Pass required dependencies explicitly. Search terms that should match this issue include g22 make logical dependencies physical, make logical dependencies physical, make logical, dependencies physical, general.\nUse when: Use this pattern when planning or reviewing code where pass required dependencies explicitly. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\npriceOrder(order, pricingRules);\nGood Python:\nprice_order(order, pricing_rules)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Pass required dependencies explicitly.\nLintability: low", "embedding_text": "Clean code pattern CC-231: G22 Make Logical Dependencies Physical. Topic: General. Rule family: clean_code. Aliases and smell terms: g22 make logical dependencies physical, make logical dependencies physical, make logical, dependencies physical, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g22 make logical dependencies physical: Pass required dependencies explicitly. Search terms that should match this issue include g22 make logical dependencies physical, make logical dependencies physical, make logical, dependencies physical, general. Use when: Use this pattern when planning or reviewing code where pass required dependencies explicitly. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Pass required dependencies explicitly.. Good TypeScript example: priceOrder(order, pricingRules); Good Python example: price_order(order, pricing_rules) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "price_order(order, pricing_rules)", "typescript": "priceOrder(order, pricingRules);"}, "id": "CC-231", "lint_candidates": ["Pass required dependencies explicitly."], "lintability": "low", "problem": "Code has a clean-code risk related to g22 make logical dependencies physical: Pass required dependencies explicitly. Search terms that should match this issue include g22 make logical dependencies physical, make logical dependencies physical, make logical, dependencies physical, general.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G22 Make Logical Dependencies Physical", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where pass required dependencies explicitly. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g23 prefer polymorphism", "prefer polymorphism", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-232 G23 Prefer Polymorphism\nTopic: General\nAliases: g23 prefer polymorphism, prefer polymorphism, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g23 prefer polymorphism: Use dispatch or polymorphism for repeated type branching. Search terms that should match this issue include g23 prefer polymorphism, prefer polymorphism, general, clean code, code smell.\nUse when: Use this pattern when planning or reviewing code where use dispatch or polymorphism for repeated type branching. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nhandlerFor(order.type).submit(order);\nGood Python:\nhandler_for(order.type).submit(order)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use dispatch or polymorphism for repeated type branching.\nLintability: low", "embedding_text": "Clean code pattern CC-232: G23 Prefer Polymorphism. Topic: General. Rule family: clean_code. Aliases and smell terms: g23 prefer polymorphism, prefer polymorphism, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g23 prefer polymorphism: Use dispatch or polymorphism for repeated type branching. Search terms that should match this issue include g23 prefer polymorphism, prefer polymorphism, general, clean code, code smell. Use when: Use this pattern when planning or reviewing code where use dispatch or polymorphism for repeated type branching. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use dispatch or polymorphism for repeated type branching.. Good TypeScript example: handlerFor(order.type).submit(order); Good Python example: handler_for(order.type).submit(order) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "handler_for(order.type).submit(order)", "typescript": "handlerFor(order.type).submit(order);"}, "id": "CC-232", "lint_candidates": ["Use dispatch or polymorphism for repeated type branching."], "lintability": "low", "problem": "Code has a clean-code risk related to g23 prefer polymorphism: Use dispatch or polymorphism for repeated type branching. Search terms that should match this issue include g23 prefer polymorphism, prefer polymorphism, general, clean code, code smell.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G23 Prefer Polymorphism", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where use dispatch or polymorphism for repeated type branching. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g24 follow standard conventions", "follow standard conventions", "follow standard", "standard conventions", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-233 G24 Follow Standard Conventions\nTopic: General\nAliases: g24 follow standard conventions, follow standard conventions, follow standard, standard conventions, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g24 follow standard conventions: Follow local and language conventions consistently. Search terms that should match this issue include g24 follow standard conventions, follow standard conventions, follow standard, standard conventions, general.\nUse when: Use this pattern when planning or reviewing code where follow local and language conventions consistently. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst createdAt = new Date();\nGood Python:\ncreated_at = datetime.now(tz=UTC)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Follow local and language conventions consistently.\nLintability: low", "embedding_text": "Clean code pattern CC-233: G24 Follow Standard Conventions. Topic: General. Rule family: clean_code. Aliases and smell terms: g24 follow standard conventions, follow standard conventions, follow standard, standard conventions, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g24 follow standard conventions: Follow local and language conventions consistently. Search terms that should match this issue include g24 follow standard conventions, follow standard conventions, follow standard, standard conventions, general. Use when: Use this pattern when planning or reviewing code where follow local and language conventions consistently. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Follow local and language conventions consistently.. Good TypeScript example: const createdAt = new Date(); Good Python example: created_at = datetime.now(tz=UTC) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "created_at = datetime.now(tz=UTC)", "typescript": "const createdAt = new Date();"}, "id": "CC-233", "lint_candidates": ["Follow local and language conventions consistently."], "lintability": "low", "problem": "Code has a clean-code risk related to g24 follow standard conventions: Follow local and language conventions consistently. Search terms that should match this issue include g24 follow standard conventions, follow standard conventions, follow standard, standard conventions, general.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G24 Follow Standard Conventions", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where follow local and language conventions consistently. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g25 named constants", "named constants", "naming smell", "identifier name", "semantic naming", "readable name", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "if failed_attempts >= 5:\n    lock_account(user_id)", "typescript": "if (failedAttempts >= 5) lockAccount(userId);"}, "display_text": "CC-234 G25 Named Constants\nTopic: General\nAliases: g25 named constants, named constants, naming smell, identifier name, semantic naming, readable name, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g25 named constants: Replace magic numbers with named constants. Search terms that should match this issue include g25 named constants, named constants, naming smell, identifier name, semantic naming.\nUse when: Use this pattern when planning or reviewing code where replace magic numbers with named constants. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nif (attempts >= MAX_RETRY_ATTEMPTS) stopRetrying();\nGood Python:\nif attempts >= MAX_RETRY_ATTEMPTS:\n    stop_retrying()\nBad TypeScript:\nif (failedAttempts >= 5) lockAccount(userId);\nBad Python:\nif failed_attempts >= 5:\n    lock_account(user_id)\nLint candidates: Replace magic numbers with named constants.\nLintability: high", "embedding_text": "Clean code pattern CC-234: G25 Named Constants. Topic: General. Rule family: naming. Aliases and smell terms: g25 named constants, named constants, naming smell, identifier name, semantic naming, readable name, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g25 named constants: Replace magic numbers with named constants. Search terms that should match this issue include g25 named constants, named constants, naming smell, identifier name, semantic naming. Use when: Use this pattern when planning or reviewing code where replace magic numbers with named constants. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Replace magic numbers with named constants.. Good TypeScript example: if (attempts >= MAX_RETRY_ATTEMPTS) stopRetrying(); Good Python example: if attempts >= MAX_RETRY_ATTEMPTS:\n    stop_retrying() Bad TypeScript example: if (failedAttempts >= 5) lockAccount(userId); Bad Python example: if failed_attempts >= 5:\n    lock_account(user_id)", "good_examples": {"python": "if attempts >= MAX_RETRY_ATTEMPTS:\n    stop_retrying()", "typescript": "if (attempts >= MAX_RETRY_ATTEMPTS) stopRetrying();"}, "id": "CC-234", "lint_candidates": ["Replace magic numbers with named constants."], "lintability": "high", "problem": "Code has a clean-code risk related to g25 named constants: Replace magic numbers with named constants. Search terms that should match this issue include g25 named constants, named constants, naming smell, identifier name, semantic naming.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G25 Named Constants", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where replace magic numbers with named constants. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["g26 be precise", "be precise", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-235 G26 Be Precise\nTopic: General\nAliases: g26 be precise, be precise, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g26 be precise: Use exact types, units, and boundary rules. Search terms that should match this issue include g26 be precise, be precise, general, clean code, code smell.\nUse when: Use this pattern when planning or reviewing code where use exact types, units, and boundary rules. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst timeoutMs: Milliseconds = 3000;\nGood Python:\ntimeout_seconds: float = 3.0\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use exact types, units, and boundary rules.\nLintability: low", "embedding_text": "Clean code pattern CC-235: G26 Be Precise. Topic: General. Rule family: clean_code. Aliases and smell terms: g26 be precise, be precise, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g26 be precise: Use exact types, units, and boundary rules. Search terms that should match this issue include g26 be precise, be precise, general, clean code, code smell. Use when: Use this pattern when planning or reviewing code where use exact types, units, and boundary rules. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use exact types, units, and boundary rules.. Good TypeScript example: const timeoutMs: Milliseconds = 3000; Good Python example: timeout_seconds: float = 3.0 Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "timeout_seconds: float = 3.0", "typescript": "const timeoutMs: Milliseconds = 3000;"}, "id": "CC-235", "lint_candidates": ["Use exact types, units, and boundary rules."], "lintability": "low", "problem": "Code has a clean-code risk related to g26 be precise: Use exact types, units, and boundary rules. Search terms that should match this issue include g26 be precise, be precise, general, clean code, code smell.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G26 Be Precise", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where use exact types, units, and boundary rules. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g27 structure over convention", "structure over convention", "structure over", "over convention", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-236 G27 Structure Over Convention\nTopic: General\nAliases: g27 structure over convention, structure over convention, structure over, over convention, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g27 structure over convention: Represent rules in code structure rather than naming conventions alone. Search terms that should match this issue include g27 structure over convention, structure over convention, structure over, over convention, general.\nUse when: Use this pattern when planning or reviewing code where represent rules in code structure rather than naming conventions alone. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst command = new SubmitOrderCommand(orderId);\nGood Python:\ncommand = SubmitOrderCommand(order_id)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Represent rules in code structure rather than naming conventions alone.\nLintability: low", "embedding_text": "Clean code pattern CC-236: G27 Structure Over Convention. Topic: General. Rule family: clean_code. Aliases and smell terms: g27 structure over convention, structure over convention, structure over, over convention, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g27 structure over convention: Represent rules in code structure rather than naming conventions alone. Search terms that should match this issue include g27 structure over convention, structure over convention, structure over, over convention, general. Use when: Use this pattern when planning or reviewing code where represent rules in code structure rather than naming conventions alone. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Represent rules in code structure rather than naming conventions alone.. Good TypeScript example: const command = new SubmitOrderCommand(orderId); Good Python example: command = SubmitOrderCommand(order_id) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "command = SubmitOrderCommand(order_id)", "typescript": "const command = new SubmitOrderCommand(orderId);"}, "id": "CC-236", "lint_candidates": ["Represent rules in code structure rather than naming conventions alone."], "lintability": "low", "problem": "Code has a clean-code risk related to g27 structure over convention: Represent rules in code structure rather than naming conventions alone. Search terms that should match this issue include g27 structure over convention, structure over convention, structure over, over convention, general.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G27 Structure Over Convention", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where represent rules in code structure rather than naming conventions alone. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g28 encapsulate conditionals", "encapsulate conditionals", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-237 G28 Encapsulate Conditionals\nTopic: General\nAliases: g28 encapsulate conditionals, encapsulate conditionals, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g28 encapsulate conditionals: Hide complex conditions behind named predicates. Search terms that should match this issue include g28 encapsulate conditionals, encapsulate conditionals, general, clean code, code smell.\nUse when: Use this pattern when planning or reviewing code where hide complex conditions behind named predicates. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nif (canRetryPayment(error, attempt)) retry();\nGood Python:\nif can_retry_payment(error, attempt):\n    retry()\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Hide complex conditions behind named predicates.\nLintability: high", "embedding_text": "Clean code pattern CC-237: G28 Encapsulate Conditionals. Topic: General. Rule family: clean_code. Aliases and smell terms: g28 encapsulate conditionals, encapsulate conditionals, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g28 encapsulate conditionals: Hide complex conditions behind named predicates. Search terms that should match this issue include g28 encapsulate conditionals, encapsulate conditionals, general, clean code, code smell. Use when: Use this pattern when planning or reviewing code where hide complex conditions behind named predicates. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Hide complex conditions behind named predicates.. Good TypeScript example: if (canRetryPayment(error, attempt)) retry(); Good Python example: if can_retry_payment(error, attempt):\n    retry() Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "if can_retry_payment(error, attempt):\n    retry()", "typescript": "if (canRetryPayment(error, attempt)) retry();"}, "id": "CC-237", "lint_candidates": ["Hide complex conditions behind named predicates."], "lintability": "high", "problem": "Code has a clean-code risk related to g28 encapsulate conditionals: Hide complex conditions behind named predicates. Search terms that should match this issue include g28 encapsulate conditionals, encapsulate conditionals, general, clean code, code smell.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G28 Encapsulate Conditionals", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where hide complex conditions behind named predicates. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g29 avoid negative conditionals", "avoid negative conditionals", "avoid negative", "negative conditionals", "negative conditional", "double negative", "positive predicate", "readable condition", "general", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "if not is_not_disabled(account):\n    allow_transfer(account)", "typescript": "if (!isNotDisabled(account)) allowTransfer(account);"}, "display_text": "CC-238 G29 Avoid Negative Conditionals\nTopic: General\nAliases: g29 avoid negative conditionals, avoid negative conditionals, avoid negative, negative conditionals, negative conditional, double negative, positive predicate, readable condition, general, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to g29 avoid negative conditionals: Prefer positive predicates and branches. Search terms that should match this issue include g29 avoid negative conditionals, avoid negative conditionals, avoid negative, negative conditionals, negative conditional.\nUse when: Use this pattern when planning or reviewing code where prefer positive predicates and branches. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nif (account.isActive) allowTransfer(account);\nGood Python:\nif account.is_active:\n    allow_transfer(account)\nBad TypeScript:\nif (!isNotDisabled(account)) allowTransfer(account);\nBad Python:\nif not is_not_disabled(account):\n    allow_transfer(account)\nLint candidates: Prefer positive predicates and branches.\nLintability: high", "embedding_text": "Clean code pattern CC-238: G29 Avoid Negative Conditionals. Topic: General. Rule family: clean_code. Aliases and smell terms: g29 avoid negative conditionals, avoid negative conditionals, avoid negative, negative conditionals, negative conditional, double negative, positive predicate, readable condition, general, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to g29 avoid negative conditionals: Prefer positive predicates and branches. Search terms that should match this issue include g29 avoid negative conditionals, avoid negative conditionals, avoid negative, negative conditionals, negative conditional. Use when: Use this pattern when planning or reviewing code where prefer positive predicates and branches. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Prefer positive predicates and branches.. Good TypeScript example: if (account.isActive) allowTransfer(account); Good Python example: if account.is_active:\n    allow_transfer(account) Bad TypeScript example: if (!isNotDisabled(account)) allowTransfer(account); Bad Python example: if not is_not_disabled(account):\n    allow_transfer(account)", "good_examples": {"python": "if account.is_active:\n    allow_transfer(account)", "typescript": "if (account.isActive) allowTransfer(account);"}, "id": "CC-238", "lint_candidates": ["Prefer positive predicates and branches."], "lintability": "high", "problem": "Code has a clean-code risk related to g29 avoid negative conditionals: Prefer positive predicates and branches. Search terms that should match this issue include g29 avoid negative conditionals, avoid negative conditionals, avoid negative, negative conditionals, negative conditional.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G29 Avoid Negative Conditionals", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where prefer positive predicates and branches. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g30 functions do one thing", "functions do one thing", "functions do", "one thing", "function smell", "single responsibility", "small function", "function design", "do one thing", "mixed responsibility", "function cohesion", "general"], "avoid_when": "Avoid extracting helpers that only hide simple logic or make the call path harder to follow.", "bad_examples": {"python": "def submit_order(payload):\n    validate(payload)\n    db.save(payload)\n    email(payload)", "typescript": "async function submitOrder(input) { validate(input); await db.save(input); await email(input); }"}, "display_text": "CC-239 G30 Functions Do One Thing\nTopic: General\nAliases: g30 functions do one thing, functions do one thing, functions do, one thing, function smell, single responsibility, small function, function design, do one thing, mixed responsibility, function cohesion, general\nProblem: Code has a clean-code risk related to g30 functions do one thing: Split functions that validate, transform, persist, and notify. Search terms that should match this issue include g30 functions do one thing, functions do one thing, functions do, one thing, function smell.\nUse when: Use this pattern when planning or reviewing code where split functions that validate, transform, persist, and notify. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects.\nAvoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow.\nGood TypeScript:\nconst order = buildOrder(validatedInput);\nGood Python:\norder = build_order(validated_input)\nBad TypeScript:\nasync function submitOrder(input) { validate(input); await db.save(input); await email(input); }\nBad Python:\ndef submit_order(payload):\n    validate(payload)\n    db.save(payload)\n    email(payload)\nLint candidates: Split functions that validate, transform, persist, and notify.\nLintability: low", "embedding_text": "Clean code pattern CC-239: G30 Functions Do One Thing. Topic: General. Rule family: functions. Aliases and smell terms: g30 functions do one thing, functions do one thing, functions do, one thing, function smell, single responsibility, small function, function design, do one thing, mixed responsibility, function cohesion, general. Problem: Code has a clean-code risk related to g30 functions do one thing: Split functions that validate, transform, persist, and notify. Search terms that should match this issue include g30 functions do one thing, functions do one thing, functions do, one thing, function smell. Use when: Use this pattern when planning or reviewing code where split functions that validate, transform, persist, and notify. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects. Avoid when: Avoid extracting helpers that only hide simple logic or make the call path harder to follow. Lint candidates: Split functions that validate, transform, persist, and notify.. Good TypeScript example: const order = buildOrder(validatedInput); Good Python example: order = build_order(validated_input) Bad TypeScript example: async function submitOrder(input) { validate(input); await db.save(input); await email(input); } Bad Python example: def submit_order(payload):\n    validate(payload)\n    db.save(payload)\n    email(payload)", "good_examples": {"python": "order = build_order(validated_input)", "typescript": "const order = buildOrder(validatedInput);"}, "id": "CC-239", "lint_candidates": ["Split functions that validate, transform, persist, and notify."], "lintability": "low", "problem": "Code has a clean-code risk related to g30 functions do one thing: Split functions that validate, transform, persist, and notify. Search terms that should match this issue include g30 functions do one thing, functions do one thing, functions do, one thing, function smell.", "rule_family": "functions", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G30 Functions Do One Thing", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where split functions that validate, transform, persist, and notify. It is especially relevant when a function mixes abstraction levels, responsibilities, or side effects."}
+{"aliases": ["g31 hidden temporal couplings", "hidden temporal couplings", "hidden temporal", "temporal couplings", "temporal coupling", "ordering dependency", "hidden sequence", "call order", "general", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-240 G31 Hidden Temporal Couplings\nTopic: General\nAliases: g31 hidden temporal couplings, hidden temporal couplings, hidden temporal, temporal couplings, temporal coupling, ordering dependency, hidden sequence, call order, general, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to g31 hidden temporal couplings: Make ordering requirements explicit in names or types. Search terms that should match this issue include g31 hidden temporal couplings, hidden temporal couplings, hidden temporal, temporal couplings, temporal coupling.\nUse when: Use this pattern when planning or reviewing code where make ordering requirements explicit in names or types. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst session = await authenticatedSession(credentials);\nGood Python:\nsession = authenticated_session(credentials)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Make ordering requirements explicit in names or types.\nLintability: low", "embedding_text": "Clean code pattern CC-240: G31 Hidden Temporal Couplings. Topic: General. Rule family: clean_code. Aliases and smell terms: g31 hidden temporal couplings, hidden temporal couplings, hidden temporal, temporal couplings, temporal coupling, ordering dependency, hidden sequence, call order, general, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to g31 hidden temporal couplings: Make ordering requirements explicit in names or types. Search terms that should match this issue include g31 hidden temporal couplings, hidden temporal couplings, hidden temporal, temporal couplings, temporal coupling. Use when: Use this pattern when planning or reviewing code where make ordering requirements explicit in names or types. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Make ordering requirements explicit in names or types.. Good TypeScript example: const session = await authenticatedSession(credentials); Good Python example: session = authenticated_session(credentials) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "session = authenticated_session(credentials)", "typescript": "const session = await authenticatedSession(credentials);"}, "id": "CC-240", "lint_candidates": ["Make ordering requirements explicit in names or types."], "lintability": "low", "problem": "Code has a clean-code risk related to g31 hidden temporal couplings: Make ordering requirements explicit in names or types. Search terms that should match this issue include g31 hidden temporal couplings, hidden temporal couplings, hidden temporal, temporal couplings, temporal coupling.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G31 Hidden Temporal Couplings", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where make ordering requirements explicit in names or types. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g32 do not be arbitrary", "do not be arbitrary", "do not", "be arbitrary", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-241 G32 Do Not Be Arbitrary\nTopic: General\nAliases: g32 do not be arbitrary, do not be arbitrary, do not, be arbitrary, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g32 do not be arbitrary: Keep structure tied to a real reason, not personal taste. Search terms that should match this issue include g32 do not be arbitrary, do not be arbitrary, do not, be arbitrary, general.\nUse when: Use this pattern when planning or reviewing code where keep structure tied to a real reason, not personal taste. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst retryPolicy = RetryPolicy.standard();\nGood Python:\nretry_policy = RetryPolicy.standard()\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Keep structure tied to a real reason, not personal taste.\nLintability: low", "embedding_text": "Clean code pattern CC-241: G32 Do Not Be Arbitrary. Topic: General. Rule family: clean_code. Aliases and smell terms: g32 do not be arbitrary, do not be arbitrary, do not, be arbitrary, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g32 do not be arbitrary: Keep structure tied to a real reason, not personal taste. Search terms that should match this issue include g32 do not be arbitrary, do not be arbitrary, do not, be arbitrary, general. Use when: Use this pattern when planning or reviewing code where keep structure tied to a real reason, not personal taste. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Keep structure tied to a real reason, not personal taste.. Good TypeScript example: const retryPolicy = RetryPolicy.standard(); Good Python example: retry_policy = RetryPolicy.standard() Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "retry_policy = RetryPolicy.standard()", "typescript": "const retryPolicy = RetryPolicy.standard();"}, "id": "CC-241", "lint_candidates": ["Keep structure tied to a real reason, not personal taste."], "lintability": "low", "problem": "Code has a clean-code risk related to g32 do not be arbitrary: Keep structure tied to a real reason, not personal taste. Search terms that should match this issue include g32 do not be arbitrary, do not be arbitrary, do not, be arbitrary, general.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G32 Do Not Be Arbitrary", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where keep structure tied to a real reason, not personal taste. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g33 encapsulate boundary conditions", "encapsulate boundary conditions", "encapsulate boundary", "boundary conditions", "boundary design", "adapter", "third party code", "integration seam", "boundary condition", "edge case", "limit", "off by one"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-242 G33 Encapsulate Boundary Conditions\nTopic: General\nAliases: g33 encapsulate boundary conditions, encapsulate boundary conditions, encapsulate boundary, boundary conditions, boundary design, adapter, third party code, integration seam, boundary condition, edge case, limit, off by one\nProblem: Code has a clean-code risk related to g33 encapsulate boundary conditions: Name edge rules and keep them in one place. Search terms that should match this issue include g33 encapsulate boundary conditions, encapsulate boundary conditions, encapsulate boundary, boundary conditions, boundary design.\nUse when: Use this pattern when planning or reviewing code where name edge rules and keep them in one place. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nreturn isWithinRefundWindow(order, now);\nGood Python:\nreturn is_within_refund_window(order, now)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Name edge rules and keep them in one place.\nLintability: low", "embedding_text": "Clean code pattern CC-242: G33 Encapsulate Boundary Conditions. Topic: General. Rule family: boundaries. Aliases and smell terms: g33 encapsulate boundary conditions, encapsulate boundary conditions, encapsulate boundary, boundary conditions, boundary design, adapter, third party code, integration seam, boundary condition, edge case, limit, off by one. Problem: Code has a clean-code risk related to g33 encapsulate boundary conditions: Name edge rules and keep them in one place. Search terms that should match this issue include g33 encapsulate boundary conditions, encapsulate boundary conditions, encapsulate boundary, boundary conditions, boundary design. Use when: Use this pattern when planning or reviewing code where name edge rules and keep them in one place. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Name edge rules and keep them in one place.. Good TypeScript example: return isWithinRefundWindow(order, now); Good Python example: return is_within_refund_window(order, now) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "return is_within_refund_window(order, now)", "typescript": "return isWithinRefundWindow(order, now);"}, "id": "CC-242", "lint_candidates": ["Name edge rules and keep them in one place."], "lintability": "low", "problem": "Code has a clean-code risk related to g33 encapsulate boundary conditions: Name edge rules and keep them in one place. Search terms that should match this issue include g33 encapsulate boundary conditions, encapsulate boundary conditions, encapsulate boundary, boundary conditions, boundary design.", "rule_family": "boundaries", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G33 Encapsulate Boundary Conditions", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where name edge rules and keep them in one place. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g34 one abstraction level", "one abstraction level", "one abstraction", "abstraction level", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-243 G34 One Abstraction Level\nTopic: General\nAliases: g34 one abstraction level, one abstraction level, one abstraction, abstraction level, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g34 one abstraction level: Keep each function at one abstraction level. Search terms that should match this issue include g34 one abstraction level, one abstraction level, one abstraction, abstraction level, general.\nUse when: Use this pattern when planning or reviewing code where keep each function at one abstraction level. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nreturn submitPricedOrder(priceOrder(order));\nGood Python:\nreturn submit_priced_order(price_order(order))\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Keep each function at one abstraction level.\nLintability: low", "embedding_text": "Clean code pattern CC-243: G34 One Abstraction Level. Topic: General. Rule family: clean_code. Aliases and smell terms: g34 one abstraction level, one abstraction level, one abstraction, abstraction level, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g34 one abstraction level: Keep each function at one abstraction level. Search terms that should match this issue include g34 one abstraction level, one abstraction level, one abstraction, abstraction level, general. Use when: Use this pattern when planning or reviewing code where keep each function at one abstraction level. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Keep each function at one abstraction level.. Good TypeScript example: return submitPricedOrder(priceOrder(order)); Good Python example: return submit_priced_order(price_order(order)) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "return submit_priced_order(price_order(order))", "typescript": "return submitPricedOrder(priceOrder(order));"}, "id": "CC-243", "lint_candidates": ["Keep each function at one abstraction level."], "lintability": "low", "problem": "Code has a clean-code risk related to g34 one abstraction level: Keep each function at one abstraction level. Search terms that should match this issue include g34 one abstraction level, one abstraction level, one abstraction, abstraction level, general.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G34 One Abstraction Level", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where keep each function at one abstraction level. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g35 configurable data high", "configurable data high", "configurable data", "data high", "data structure", "object design", "encapsulation", "data abstraction", "general", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-244 G35 Configurable Data High\nTopic: General\nAliases: g35 configurable data high, configurable data high, configurable data, data high, data structure, object design, encapsulation, data abstraction, general, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to g35 configurable data high: Keep configuration values near startup or module configuration. Search terms that should match this issue include g35 configurable data high, configurable data high, configurable data, data high, data structure.\nUse when: Use this pattern when planning or reviewing code where keep configuration values near startup or module configuration. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst settings = loadPaymentSettings(env);\nGood Python:\nsettings = load_payment_settings(env)\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Keep configuration values near startup or module configuration.\nLintability: low", "embedding_text": "Clean code pattern CC-244: G35 Configurable Data High. Topic: General. Rule family: objects_data. Aliases and smell terms: g35 configurable data high, configurable data high, configurable data, data high, data structure, object design, encapsulation, data abstraction, general, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to g35 configurable data high: Keep configuration values near startup or module configuration. Search terms that should match this issue include g35 configurable data high, configurable data high, configurable data, data high, data structure. Use when: Use this pattern when planning or reviewing code where keep configuration values near startup or module configuration. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Keep configuration values near startup or module configuration.. Good TypeScript example: const settings = loadPaymentSettings(env); Good Python example: settings = load_payment_settings(env) Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "settings = load_payment_settings(env)", "typescript": "const settings = loadPaymentSettings(env);"}, "id": "CC-244", "lint_candidates": ["Keep configuration values near startup or module configuration."], "lintability": "low", "problem": "Code has a clean-code risk related to g35 configurable data high: Keep configuration values near startup or module configuration. Search terms that should match this issue include g35 configurable data high, configurable data high, configurable data, data high, data structure.", "rule_family": "objects_data", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G35 Configurable Data High", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where keep configuration values near startup or module configuration. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["g36 avoid transitive navigation", "avoid transitive navigation", "avoid transitive", "transitive navigation", "general", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "city = order.customer.address.city", "typescript": "const city = order.customer.address.city;"}, "display_text": "CC-245 G36 Avoid Transitive Navigation\nTopic: General\nAliases: g36 avoid transitive navigation, avoid transitive navigation, avoid transitive, transitive navigation, general, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to g36 avoid transitive navigation: Avoid chains that expose object internals. Search terms that should match this issue include g36 avoid transitive navigation, avoid transitive navigation, avoid transitive, transitive navigation, general.\nUse when: Use this pattern when planning or reviewing code where avoid chains that expose object internals. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nconst region = customer.billingRegion();\nGood Python:\nregion = customer.billing_region()\nBad TypeScript:\nconst city = order.customer.address.city;\nBad Python:\ncity = order.customer.address.city\nLint candidates: Avoid chains that expose object internals.\nLintability: low", "embedding_text": "Clean code pattern CC-245: G36 Avoid Transitive Navigation. Topic: General. Rule family: clean_code. Aliases and smell terms: g36 avoid transitive navigation, avoid transitive navigation, avoid transitive, transitive navigation, general, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to g36 avoid transitive navigation: Avoid chains that expose object internals. Search terms that should match this issue include g36 avoid transitive navigation, avoid transitive navigation, avoid transitive, transitive navigation, general. Use when: Use this pattern when planning or reviewing code where avoid chains that expose object internals. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Avoid chains that expose object internals.. Good TypeScript example: const region = customer.billingRegion(); Good Python example: region = customer.billing_region() Bad TypeScript example: const city = order.customer.address.city; Bad Python example: city = order.customer.address.city", "good_examples": {"python": "region = customer.billing_region()", "typescript": "const region = customer.billingRegion();"}, "id": "CC-245", "lint_candidates": ["Avoid chains that expose object internals."], "lintability": "low", "problem": "Code has a clean-code risk related to g36 avoid transitive navigation: Avoid chains that expose object internals. Search terms that should match this issue include g36 avoid transitive navigation, avoid transitive navigation, avoid transitive, transitive navigation, general.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "G36 Avoid Transitive Navigation", "topic": "General", "use_when": "Use this pattern when planning or reviewing code where avoid chains that expose object internals. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["j1 avoid long import lists", "avoid long import lists", "avoid long", "import lists", "import list", "dependency list", "module dependency", "wildcard import", "java", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-246 J1 Avoid Long Import Lists\nTopic: Java\nAliases: j1 avoid long import lists, avoid long import lists, avoid long, import lists, import list, dependency list, module dependency, wildcard import, java, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to j1 avoid long import lists: Prefer module-level imports that keep dependency lists readable in languages that support them. Search terms that should match this issue include j1 avoid long import lists, avoid long import lists, avoid long, import lists, import list.\nUse when: Use this pattern when planning or reviewing code where prefer module-level imports that keep dependency lists readable in languages that support them. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nimport { OrderService } from './orders';\nGood Python:\nfrom orders import OrderService\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Prefer module-level imports that keep dependency lists readable in languages that support them.\nLintability: high", "embedding_text": "Clean code pattern CC-246: J1 Avoid Long Import Lists. Topic: Java. Rule family: clean_code. Aliases and smell terms: j1 avoid long import lists, avoid long import lists, avoid long, import lists, import list, dependency list, module dependency, wildcard import, java, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to j1 avoid long import lists: Prefer module-level imports that keep dependency lists readable in languages that support them. Search terms that should match this issue include j1 avoid long import lists, avoid long import lists, avoid long, import lists, import list. Use when: Use this pattern when planning or reviewing code where prefer module-level imports that keep dependency lists readable in languages that support them. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Prefer module-level imports that keep dependency lists readable in languages that support them.. Good TypeScript example: import { OrderService } from './orders'; Good Python example: from orders import OrderService Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "from orders import OrderService", "typescript": "import { OrderService } from './orders';"}, "id": "CC-246", "lint_candidates": ["Prefer module-level imports that keep dependency lists readable in languages that support them."], "lintability": "high", "problem": "Code has a clean-code risk related to j1 avoid long import lists: Prefer module-level imports that keep dependency lists readable in languages that support them. Search terms that should match this issue include j1 avoid long import lists, avoid long import lists, avoid long, import lists, import list.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "J1 Avoid Long Import Lists", "topic": "Java", "use_when": "Use this pattern when planning or reviewing code where prefer module-level imports that keep dependency lists readable in languages that support them. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["j2 do not inherit constants", "do not inherit constants", "do not", "inherit constants", "java", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-247 J2 Do Not Inherit Constants\nTopic: Java\nAliases: j2 do not inherit constants, do not inherit constants, do not, inherit constants, java, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to j2 do not inherit constants: Use explicit constants modules or enums instead of inherited constant bags. Search terms that should match this issue include j2 do not inherit constants, do not inherit constants, do not, inherit constants, java.\nUse when: Use this pattern when planning or reviewing code where use explicit constants modules or enums instead of inherited constant bags. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nOrderStatus.Paid\nGood Python:\nOrderStatus.PAID\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use explicit constants modules or enums instead of inherited constant bags.\nLintability: low", "embedding_text": "Clean code pattern CC-247: J2 Do Not Inherit Constants. Topic: Java. Rule family: clean_code. Aliases and smell terms: j2 do not inherit constants, do not inherit constants, do not, inherit constants, java, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to j2 do not inherit constants: Use explicit constants modules or enums instead of inherited constant bags. Search terms that should match this issue include j2 do not inherit constants, do not inherit constants, do not, inherit constants, java. Use when: Use this pattern when planning or reviewing code where use explicit constants modules or enums instead of inherited constant bags. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use explicit constants modules or enums instead of inherited constant bags.. Good TypeScript example: OrderStatus.Paid Good Python example: OrderStatus.PAID Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "OrderStatus.PAID", "typescript": "OrderStatus.Paid"}, "id": "CC-247", "lint_candidates": ["Use explicit constants modules or enums instead of inherited constant bags."], "lintability": "low", "problem": "Code has a clean-code risk related to j2 do not inherit constants: Use explicit constants modules or enums instead of inherited constant bags. Search terms that should match this issue include j2 do not inherit constants, do not inherit constants, do not, inherit constants, java.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "J2 Do Not Inherit Constants", "topic": "Java", "use_when": "Use this pattern when planning or reviewing code where use explicit constants modules or enums instead of inherited constant bags. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["j3 constants versus enums", "constants versus enums", "constants versus", "versus enums", "enum", "closed set", "constant group", "named variants", "java", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.", "bad_examples": {"python": "result = process(data)", "typescript": "const result = process(data);"}, "display_text": "CC-248 J3 Constants Versus Enums\nTopic: Java\nAliases: j3 constants versus enums, constants versus enums, constants versus, versus enums, enum, closed set, constant group, named variants, java, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to j3 constants versus enums: Use enums for closed sets with meaning. Search terms that should match this issue include j3 constants versus enums, constants versus enums, constants versus, versus enums, enum.\nUse when: Use this pattern when planning or reviewing code where use enums for closed sets with meaning. It is relevant when the pattern makes the code easier to change without hiding local conventions.\nAvoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better.\nGood TypeScript:\nenum OrderStatus { Draft, Paid, Cancelled }\nGood Python:\nclass OrderStatus(Enum):\n    DRAFT = 'draft'\n    PAID = 'paid'\nBad TypeScript:\nconst result = process(data);\nBad Python:\nresult = process(data)\nLint candidates: Use enums for closed sets with meaning.\nLintability: low", "embedding_text": "Clean code pattern CC-248: J3 Constants Versus Enums. Topic: Java. Rule family: clean_code. Aliases and smell terms: j3 constants versus enums, constants versus enums, constants versus, versus enums, enum, closed set, constant group, named variants, java, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to j3 constants versus enums: Use enums for closed sets with meaning. Search terms that should match this issue include j3 constants versus enums, constants versus enums, constants versus, versus enums, enum. Use when: Use this pattern when planning or reviewing code where use enums for closed sets with meaning. It is relevant when the pattern makes the code easier to change without hiding local conventions. Avoid when: Avoid applying this mechanically when local project conventions or a simpler direct implementation communicate the intent better. Lint candidates: Use enums for closed sets with meaning.. Good TypeScript example: enum OrderStatus { Draft, Paid, Cancelled } Good Python example: class OrderStatus(Enum):\n    DRAFT = 'draft'\n    PAID = 'paid' Bad TypeScript example: const result = process(data); Bad Python example: result = process(data)", "good_examples": {"python": "class OrderStatus(Enum):\n    DRAFT = 'draft'\n    PAID = 'paid'", "typescript": "enum OrderStatus { Draft, Paid, Cancelled }"}, "id": "CC-248", "lint_candidates": ["Use enums for closed sets with meaning."], "lintability": "low", "problem": "Code has a clean-code risk related to j3 constants versus enums: Use enums for closed sets with meaning. Search terms that should match this issue include j3 constants versus enums, constants versus enums, constants versus, versus enums, enum.", "rule_family": "clean_code", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "J3 Constants Versus Enums", "topic": "Java", "use_when": "Use this pattern when planning or reviewing code where use enums for closed sets with meaning. It is relevant when the pattern makes the code easier to change without hiding local conventions."}
+{"aliases": ["n1 descriptive names", "descriptive names", "naming smell", "identifier name", "semantic naming", "readable name", "names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-249 N1 Descriptive Names\nTopic: Names\nAliases: n1 descriptive names, descriptive names, naming smell, identifier name, semantic naming, readable name, names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to n1 descriptive names: Choose names that reveal intent. Search terms that should match this issue include n1 descriptive names, descriptive names, naming smell, identifier name, semantic naming.\nUse when: Use this pattern when planning or reviewing code where choose names that reveal intent. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst overdueInvoices = invoices.filter(isOverdue);\nGood Python:\noverdue_invoices = [invoice for invoice in invoices if is_overdue(invoice)]\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Choose names that reveal intent.\nLintability: low", "embedding_text": "Clean code pattern CC-249: N1 Descriptive Names. Topic: Names. Rule family: naming. Aliases and smell terms: n1 descriptive names, descriptive names, naming smell, identifier name, semantic naming, readable name, names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to n1 descriptive names: Choose names that reveal intent. Search terms that should match this issue include n1 descriptive names, descriptive names, naming smell, identifier name, semantic naming. Use when: Use this pattern when planning or reviewing code where choose names that reveal intent. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Choose names that reveal intent.. Good TypeScript example: const overdueInvoices = invoices.filter(isOverdue); Good Python example: overdue_invoices = [invoice for invoice in invoices if is_overdue(invoice)] Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "overdue_invoices = [invoice for invoice in invoices if is_overdue(invoice)]", "typescript": "const overdueInvoices = invoices.filter(isOverdue);"}, "id": "CC-249", "lint_candidates": ["Choose names that reveal intent."], "lintability": "low", "problem": "Code has a clean-code risk related to n1 descriptive names: Choose names that reveal intent. Search terms that should match this issue include n1 descriptive names, descriptive names, naming smell, identifier name, semantic naming.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "N1 Descriptive Names", "topic": "Names", "use_when": "Use this pattern when planning or reviewing code where choose names that reveal intent. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["n2 names at appropriate abstraction", "names at appropriate abstraction", "names at", "appropriate abstraction", "naming smell", "identifier name", "semantic naming", "readable name", "names", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-250 N2 Names At Appropriate Abstraction\nTopic: Names\nAliases: n2 names at appropriate abstraction, names at appropriate abstraction, names at, appropriate abstraction, naming smell, identifier name, semantic naming, readable name, names, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to n2 names at appropriate abstraction: Name things at the level callers need. Search terms that should match this issue include n2 names at appropriate abstraction, names at appropriate abstraction, names at, appropriate abstraction, naming smell.\nUse when: Use this pattern when planning or reviewing code where name things at the level callers need. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst settlement = settlementPolicy.settle(order);\nGood Python:\nsettlement = settlement_policy.settle(order)\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Name things at the level callers need.\nLintability: low", "embedding_text": "Clean code pattern CC-250: N2 Names At Appropriate Abstraction. Topic: Names. Rule family: naming. Aliases and smell terms: n2 names at appropriate abstraction, names at appropriate abstraction, names at, appropriate abstraction, naming smell, identifier name, semantic naming, readable name, names, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to n2 names at appropriate abstraction: Name things at the level callers need. Search terms that should match this issue include n2 names at appropriate abstraction, names at appropriate abstraction, names at, appropriate abstraction, naming smell. Use when: Use this pattern when planning or reviewing code where name things at the level callers need. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Name things at the level callers need.. Good TypeScript example: const settlement = settlementPolicy.settle(order); Good Python example: settlement = settlement_policy.settle(order) Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "settlement = settlement_policy.settle(order)", "typescript": "const settlement = settlementPolicy.settle(order);"}, "id": "CC-250", "lint_candidates": ["Name things at the level callers need."], "lintability": "low", "problem": "Code has a clean-code risk related to n2 names at appropriate abstraction: Name things at the level callers need. Search terms that should match this issue include n2 names at appropriate abstraction, names at appropriate abstraction, names at, appropriate abstraction, naming smell.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "N2 Names At Appropriate Abstraction", "topic": "Names", "use_when": "Use this pattern when planning or reviewing code where name things at the level callers need. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["n3 standard nomenclature", "standard nomenclature", "naming smell", "identifier name", "semantic naming", "readable name", "names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-251 N3 Standard Nomenclature\nTopic: Names\nAliases: n3 standard nomenclature, standard nomenclature, naming smell, identifier name, semantic naming, readable name, names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to n3 standard nomenclature: Use established names for known patterns and domain terms. Search terms that should match this issue include n3 standard nomenclature, standard nomenclature, naming smell, identifier name, semantic naming.\nUse when: Use this pattern when planning or reviewing code where use established names for known patterns and domain terms. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nclass OrderRepository {}\nGood Python:\nclass OrderRepository: pass\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Use established names for known patterns and domain terms.\nLintability: low", "embedding_text": "Clean code pattern CC-251: N3 Standard Nomenclature. Topic: Names. Rule family: naming. Aliases and smell terms: n3 standard nomenclature, standard nomenclature, naming smell, identifier name, semantic naming, readable name, names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to n3 standard nomenclature: Use established names for known patterns and domain terms. Search terms that should match this issue include n3 standard nomenclature, standard nomenclature, naming smell, identifier name, semantic naming. Use when: Use this pattern when planning or reviewing code where use established names for known patterns and domain terms. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Use established names for known patterns and domain terms.. Good TypeScript example: class OrderRepository {} Good Python example: class OrderRepository: pass Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "class OrderRepository: pass", "typescript": "class OrderRepository {}"}, "id": "CC-251", "lint_candidates": ["Use established names for known patterns and domain terms."], "lintability": "low", "problem": "Code has a clean-code risk related to n3 standard nomenclature: Use established names for known patterns and domain terms. Search terms that should match this issue include n3 standard nomenclature, standard nomenclature, naming smell, identifier name, semantic naming.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "N3 Standard Nomenclature", "topic": "Names", "use_when": "Use this pattern when planning or reviewing code where use established names for known patterns and domain terms. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["n4 unambiguous names", "unambiguous names", "naming smell", "identifier name", "semantic naming", "readable name", "names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-252 N4 Unambiguous Names\nTopic: Names\nAliases: n4 unambiguous names, unambiguous names, naming smell, identifier name, semantic naming, readable name, names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to n4 unambiguous names: Avoid names that can mean multiple things. Search terms that should match this issue include n4 unambiguous names, unambiguous names, naming smell, identifier name, semantic naming.\nUse when: Use this pattern when planning or reviewing code where avoid names that can mean multiple things. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst billingAddress = customer.billingAddress;\nGood Python:\nbilling_address = customer.billing_address\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Avoid names that can mean multiple things.\nLintability: low", "embedding_text": "Clean code pattern CC-252: N4 Unambiguous Names. Topic: Names. Rule family: naming. Aliases and smell terms: n4 unambiguous names, unambiguous names, naming smell, identifier name, semantic naming, readable name, names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to n4 unambiguous names: Avoid names that can mean multiple things. Search terms that should match this issue include n4 unambiguous names, unambiguous names, naming smell, identifier name, semantic naming. Use when: Use this pattern when planning or reviewing code where avoid names that can mean multiple things. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Avoid names that can mean multiple things.. Good TypeScript example: const billingAddress = customer.billingAddress; Good Python example: billing_address = customer.billing_address Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "billing_address = customer.billing_address", "typescript": "const billingAddress = customer.billingAddress;"}, "id": "CC-252", "lint_candidates": ["Avoid names that can mean multiple things."], "lintability": "low", "problem": "Code has a clean-code risk related to n4 unambiguous names: Avoid names that can mean multiple things. Search terms that should match this issue include n4 unambiguous names, unambiguous names, naming smell, identifier name, semantic naming.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "N4 Unambiguous Names", "topic": "Names", "use_when": "Use this pattern when planning or reviewing code where avoid names that can mean multiple things. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["n5 long names long scopes", "long names long scopes", "long names", "long scopes", "naming smell", "identifier name", "semantic naming", "readable name", "names", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-253 N5 Long Names Long Scopes\nTopic: Names\nAliases: n5 long names long scopes, long names long scopes, long names, long scopes, naming smell, identifier name, semantic naming, readable name, names, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to n5 long names long scopes: Use longer names when a variable lives farther from its declaration. Search terms that should match this issue include n5 long names long scopes, long names long scopes, long names, long scopes, naming smell.\nUse when: Use this pattern when planning or reviewing code where use longer names when a variable lives farther from its declaration. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst pendingSettlementTransactions = loadPendingSettlementTransactions();\nGood Python:\npending_settlement_transactions = load_pending_settlement_transactions()\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Use longer names when a variable lives farther from its declaration.\nLintability: high", "embedding_text": "Clean code pattern CC-253: N5 Long Names Long Scopes. Topic: Names. Rule family: naming. Aliases and smell terms: n5 long names long scopes, long names long scopes, long names, long scopes, naming smell, identifier name, semantic naming, readable name, names, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to n5 long names long scopes: Use longer names when a variable lives farther from its declaration. Search terms that should match this issue include n5 long names long scopes, long names long scopes, long names, long scopes, naming smell. Use when: Use this pattern when planning or reviewing code where use longer names when a variable lives farther from its declaration. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Use longer names when a variable lives farther from its declaration.. Good TypeScript example: const pendingSettlementTransactions = loadPendingSettlementTransactions(); Good Python example: pending_settlement_transactions = load_pending_settlement_transactions() Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "pending_settlement_transactions = load_pending_settlement_transactions()", "typescript": "const pendingSettlementTransactions = loadPendingSettlementTransactions();"}, "id": "CC-253", "lint_candidates": ["Use longer names when a variable lives farther from its declaration."], "lintability": "high", "problem": "Code has a clean-code risk related to n5 long names long scopes: Use longer names when a variable lives farther from its declaration. Search terms that should match this issue include n5 long names long scopes, long names long scopes, long names, long scopes, naming smell.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "N5 Long Names Long Scopes", "topic": "Names", "use_when": "Use this pattern when planning or reviewing code where use longer names when a variable lives farther from its declaration. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["n6 avoid encodings", "avoid encodings", "naming smell", "identifier name", "semantic naming", "readable name", "names", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-254 N6 Avoid Encodings\nTopic: Names\nAliases: n6 avoid encodings, avoid encodings, naming smell, identifier name, semantic naming, readable name, names, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to n6 avoid encodings: Do not encode type or scope prefixes into names. Search terms that should match this issue include n6 avoid encodings, avoid encodings, naming smell, identifier name, semantic naming.\nUse when: Use this pattern when planning or reviewing code where do not encode type or scope prefixes into names. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nconst customerIds = customers.map(customer => customer.id);\nGood Python:\ncustomer_ids = [customer.id for customer in customers]\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Do not encode type or scope prefixes into names.\nLintability: low", "embedding_text": "Clean code pattern CC-254: N6 Avoid Encodings. Topic: Names. Rule family: naming. Aliases and smell terms: n6 avoid encodings, avoid encodings, naming smell, identifier name, semantic naming, readable name, names, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to n6 avoid encodings: Do not encode type or scope prefixes into names. Search terms that should match this issue include n6 avoid encodings, avoid encodings, naming smell, identifier name, semantic naming. Use when: Use this pattern when planning or reviewing code where do not encode type or scope prefixes into names. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Do not encode type or scope prefixes into names.. Good TypeScript example: const customerIds = customers.map(customer => customer.id); Good Python example: customer_ids = [customer.id for customer in customers] Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "customer_ids = [customer.id for customer in customers]", "typescript": "const customerIds = customers.map(customer => customer.id);"}, "id": "CC-254", "lint_candidates": ["Do not encode type or scope prefixes into names."], "lintability": "low", "problem": "Code has a clean-code risk related to n6 avoid encodings: Do not encode type or scope prefixes into names. Search terms that should match this issue include n6 avoid encodings, avoid encodings, naming smell, identifier name, semantic naming.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "N6 Avoid Encodings", "topic": "Names", "use_when": "Use this pattern when planning or reviewing code where do not encode type or scope prefixes into names. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["n7 names describe side effects", "names describe side effects", "names describe", "side effects", "naming smell", "identifier name", "semantic naming", "readable name", "hidden side effect", "mutation", "command query separation", "unexpected write"], "avoid_when": "Avoid renaming when the current term is a stable domain word, public API name, or project convention.", "bad_examples": {"python": "data = get_data(x)", "typescript": "const data = getData(x);"}, "display_text": "CC-255 N7 Names Describe Side Effects\nTopic: Names\nAliases: n7 names describe side effects, names describe side effects, names describe, side effects, naming smell, identifier name, semantic naming, readable name, hidden side effect, mutation, command query separation, unexpected write\nProblem: Code has a clean-code risk related to n7 names describe side effects: Function names should reveal mutation or I/O. Search terms that should match this issue include n7 names describe side effects, names describe side effects, names describe, side effects, naming smell.\nUse when: Use this pattern when planning or reviewing code where function names should reveal mutation or I/O. It is especially relevant when readers must translate vague identifiers into domain meaning.\nAvoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention.\nGood TypeScript:\nsaveAndPublishOrder(order);\nGood Python:\nsave_and_publish_order(order)\nBad TypeScript:\nconst data = getData(x);\nBad Python:\ndata = get_data(x)\nLint candidates: Function names should reveal mutation or I/O.\nLintability: low", "embedding_text": "Clean code pattern CC-255: N7 Names Describe Side Effects. Topic: Names. Rule family: naming. Aliases and smell terms: n7 names describe side effects, names describe side effects, names describe, side effects, naming smell, identifier name, semantic naming, readable name, hidden side effect, mutation, command query separation, unexpected write. Problem: Code has a clean-code risk related to n7 names describe side effects: Function names should reveal mutation or I/O. Search terms that should match this issue include n7 names describe side effects, names describe side effects, names describe, side effects, naming smell. Use when: Use this pattern when planning or reviewing code where function names should reveal mutation or I/O. It is especially relevant when readers must translate vague identifiers into domain meaning. Avoid when: Avoid renaming when the current term is a stable domain word, public API name, or project convention. Lint candidates: Function names should reveal mutation or I/O.. Good TypeScript example: saveAndPublishOrder(order); Good Python example: save_and_publish_order(order) Bad TypeScript example: const data = getData(x); Bad Python example: data = get_data(x)", "good_examples": {"python": "save_and_publish_order(order)", "typescript": "saveAndPublishOrder(order);"}, "id": "CC-255", "lint_candidates": ["Function names should reveal mutation or I/O."], "lintability": "low", "problem": "Code has a clean-code risk related to n7 names describe side effects: Function names should reveal mutation or I/O. Search terms that should match this issue include n7 names describe side effects, names describe side effects, names describe, side effects, naming smell.", "rule_family": "naming", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "N7 Names Describe Side Effects", "topic": "Names", "use_when": "Use this pattern when planning or reviewing code where function names should reveal mutation or I/O. It is especially relevant when readers must translate vague identifiers into domain meaning."}
+{"aliases": ["t1 insufficient tests", "insufficient tests", "unit test", "test smell", "test design", "test quality", "tests", "clean code", "code smell", "planning guidance", "refactoring rule"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-256 T1 Insufficient Tests\nTopic: Tests\nAliases: t1 insufficient tests, insufficient tests, unit test, test smell, test design, test quality, tests, clean code, code smell, planning guidance, refactoring rule\nProblem: Code has a clean-code risk related to t1 insufficient tests: Cover expected behavior, failure paths, and important edges. Search terms that should match this issue include t1 insufficient tests, insufficient tests, unit test, test smell, test design.\nUse when: Use this pattern when planning or reviewing code where cover expected behavior, failure paths, and important edges. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nexpect(calculateFee(zero)).toEqual(MINIMUM_FEE);\nGood Python:\nassert calculate_fee(zero) == MINIMUM_FEE\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Cover expected behavior, failure paths, and important edges.\nLintability: high", "embedding_text": "Clean code pattern CC-256: T1 Insufficient Tests. Topic: Tests. Rule family: tests. Aliases and smell terms: t1 insufficient tests, insufficient tests, unit test, test smell, test design, test quality, tests, clean code, code smell, planning guidance, refactoring rule. Problem: Code has a clean-code risk related to t1 insufficient tests: Cover expected behavior, failure paths, and important edges. Search terms that should match this issue include t1 insufficient tests, insufficient tests, unit test, test smell, test design. Use when: Use this pattern when planning or reviewing code where cover expected behavior, failure paths, and important edges. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Cover expected behavior, failure paths, and important edges.. Good TypeScript example: expect(calculateFee(zero)).toEqual(MINIMUM_FEE); Good Python example: assert calculate_fee(zero) == MINIMUM_FEE Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "assert calculate_fee(zero) == MINIMUM_FEE", "typescript": "expect(calculateFee(zero)).toEqual(MINIMUM_FEE);"}, "id": "CC-256", "lint_candidates": ["Cover expected behavior, failure paths, and important edges."], "lintability": "high", "problem": "Code has a clean-code risk related to t1 insufficient tests: Cover expected behavior, failure paths, and important edges. Search terms that should match this issue include t1 insufficient tests, insufficient tests, unit test, test smell, test design.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "T1 Insufficient Tests", "topic": "Tests", "use_when": "Use this pattern when planning or reviewing code where cover expected behavior, failure paths, and important edges. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["t2 use coverage tool", "use coverage tool", "use coverage", "coverage tool", "unit test", "test smell", "test design", "test quality", "tests", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-257 T2 Use Coverage Tool\nTopic: Tests\nAliases: t2 use coverage tool, use coverage tool, use coverage, coverage tool, unit test, test smell, test design, test quality, tests, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to t2 use coverage tool: Use coverage to discover untested areas, then add meaningful tests. Search terms that should match this issue include t2 use coverage tool, use coverage tool, use coverage, coverage tool, unit test.\nUse when: Use this pattern when planning or reviewing code where use coverage to discover untested areas, then add meaningful tests. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nexpect(coverage.forFile('pricing')).toBeGreaterThan(90);\nGood Python:\nassert coverage.for_file('pricing') > 90\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Use coverage to discover untested areas, then add meaningful tests.\nLintability: high", "embedding_text": "Clean code pattern CC-257: T2 Use Coverage Tool. Topic: Tests. Rule family: tests. Aliases and smell terms: t2 use coverage tool, use coverage tool, use coverage, coverage tool, unit test, test smell, test design, test quality, tests, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to t2 use coverage tool: Use coverage to discover untested areas, then add meaningful tests. Search terms that should match this issue include t2 use coverage tool, use coverage tool, use coverage, coverage tool, unit test. Use when: Use this pattern when planning or reviewing code where use coverage to discover untested areas, then add meaningful tests. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Use coverage to discover untested areas, then add meaningful tests.. Good TypeScript example: expect(coverage.forFile('pricing')).toBeGreaterThan(90); Good Python example: assert coverage.for_file('pricing') > 90 Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "assert coverage.for_file('pricing') > 90", "typescript": "expect(coverage.forFile('pricing')).toBeGreaterThan(90);"}, "id": "CC-257", "lint_candidates": ["Use coverage to discover untested areas, then add meaningful tests."], "lintability": "high", "problem": "Code has a clean-code risk related to t2 use coverage tool: Use coverage to discover untested areas, then add meaningful tests. Search terms that should match this issue include t2 use coverage tool, use coverage tool, use coverage, coverage tool, unit test.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "T2 Use Coverage Tool", "topic": "Tests", "use_when": "Use this pattern when planning or reviewing code where use coverage to discover untested areas, then add meaningful tests. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["t3 do not skip trivial tests", "do not skip trivial tests", "do not", "trivial tests", "unit test", "test smell", "test design", "test quality", "tests", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-258 T3 Do Not Skip Trivial Tests\nTopic: Tests\nAliases: t3 do not skip trivial tests, do not skip trivial tests, do not, trivial tests, unit test, test smell, test design, test quality, tests, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to t3 do not skip trivial tests: Small obvious rules still deserve tests when they carry policy. Search terms that should match this issue include t3 do not skip trivial tests, do not skip trivial tests, do not, trivial tests, unit test.\nUse when: Use this pattern when planning or reviewing code where small obvious rules still deserve tests when they carry policy. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nexpect(isBusinessDay(saturday)).toBe(false);\nGood Python:\nassert not is_business_day(saturday)\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Small obvious rules still deserve tests when they carry policy.\nLintability: low", "embedding_text": "Clean code pattern CC-258: T3 Do Not Skip Trivial Tests. Topic: Tests. Rule family: tests. Aliases and smell terms: t3 do not skip trivial tests, do not skip trivial tests, do not, trivial tests, unit test, test smell, test design, test quality, tests, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to t3 do not skip trivial tests: Small obvious rules still deserve tests when they carry policy. Search terms that should match this issue include t3 do not skip trivial tests, do not skip trivial tests, do not, trivial tests, unit test. Use when: Use this pattern when planning or reviewing code where small obvious rules still deserve tests when they carry policy. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Small obvious rules still deserve tests when they carry policy.. Good TypeScript example: expect(isBusinessDay(saturday)).toBe(false); Good Python example: assert not is_business_day(saturday) Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "assert not is_business_day(saturday)", "typescript": "expect(isBusinessDay(saturday)).toBe(false);"}, "id": "CC-258", "lint_candidates": ["Small obvious rules still deserve tests when they carry policy."], "lintability": "low", "problem": "Code has a clean-code risk related to t3 do not skip trivial tests: Small obvious rules still deserve tests when they carry policy. Search terms that should match this issue include t3 do not skip trivial tests, do not skip trivial tests, do not, trivial tests, unit test.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "T3 Do Not Skip Trivial Tests", "topic": "Tests", "use_when": "Use this pattern when planning or reviewing code where small obvious rules still deserve tests when they carry policy. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["t4 ignored test signals ambiguity", "ignored test signals ambiguity", "ignored test", "signals ambiguity", "unit test", "test smell", "test design", "test quality", "tests", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-259 T4 Ignored Test Signals Ambiguity\nTopic: Tests\nAliases: t4 ignored test signals ambiguity, ignored test signals ambiguity, ignored test, signals ambiguity, unit test, test smell, test design, test quality, tests, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to t4 ignored test signals ambiguity: Treat skipped tests as unresolved questions. Search terms that should match this issue include t4 ignored test signals ambiguity, ignored test signals ambiguity, ignored test, signals ambiguity, unit test.\nUse when: Use this pattern when planning or reviewing code where treat skipped tests as unresolved questions. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nit('documents the disputed rounding rule', () => expect(roundTax(value)).toEqual(expected));\nGood Python:\ndef test_documents_disputed_rounding_rule():\n    assert round_tax(value) == expected\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Treat skipped tests as unresolved questions.\nLintability: low", "embedding_text": "Clean code pattern CC-259: T4 Ignored Test Signals Ambiguity. Topic: Tests. Rule family: tests. Aliases and smell terms: t4 ignored test signals ambiguity, ignored test signals ambiguity, ignored test, signals ambiguity, unit test, test smell, test design, test quality, tests, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to t4 ignored test signals ambiguity: Treat skipped tests as unresolved questions. Search terms that should match this issue include t4 ignored test signals ambiguity, ignored test signals ambiguity, ignored test, signals ambiguity, unit test. Use when: Use this pattern when planning or reviewing code where treat skipped tests as unresolved questions. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Treat skipped tests as unresolved questions.. Good TypeScript example: it('documents the disputed rounding rule', () => expect(roundTax(value)).toEqual(expected)); Good Python example: def test_documents_disputed_rounding_rule():\n    assert round_tax(value) == expected Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "def test_documents_disputed_rounding_rule():\n    assert round_tax(value) == expected", "typescript": "it('documents the disputed rounding rule', () => expect(roundTax(value)).toEqual(expected));"}, "id": "CC-259", "lint_candidates": ["Treat skipped tests as unresolved questions."], "lintability": "low", "problem": "Code has a clean-code risk related to t4 ignored test signals ambiguity: Treat skipped tests as unresolved questions. Search terms that should match this issue include t4 ignored test signals ambiguity, ignored test signals ambiguity, ignored test, signals ambiguity, unit test.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "T4 Ignored Test Signals Ambiguity", "topic": "Tests", "use_when": "Use this pattern when planning or reviewing code where treat skipped tests as unresolved questions. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["t5 test boundary conditions", "test boundary conditions", "test boundary", "boundary conditions", "unit test", "test smell", "test design", "test quality", "boundary condition", "edge case", "limit", "off by one"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-260 T5 Test Boundary Conditions\nTopic: Tests\nAliases: t5 test boundary conditions, test boundary conditions, test boundary, boundary conditions, unit test, test smell, test design, test quality, boundary condition, edge case, limit, off by one\nProblem: Code has a clean-code risk related to t5 test boundary conditions: Test just below, at, and just above important limits. Search terms that should match this issue include t5 test boundary conditions, test boundary conditions, test boundary, boundary conditions, unit test.\nUse when: Use this pattern when planning or reviewing code where test just below, at, and just above important limits. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nexpect(canWithdraw(MINIMUM_WITHDRAWAL)).toBe(true);\nGood Python:\nassert can_withdraw(MINIMUM_WITHDRAWAL)\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Test just below, at, and just above important limits.\nLintability: high", "embedding_text": "Clean code pattern CC-260: T5 Test Boundary Conditions. Topic: Tests. Rule family: tests. Aliases and smell terms: t5 test boundary conditions, test boundary conditions, test boundary, boundary conditions, unit test, test smell, test design, test quality, boundary condition, edge case, limit, off by one. Problem: Code has a clean-code risk related to t5 test boundary conditions: Test just below, at, and just above important limits. Search terms that should match this issue include t5 test boundary conditions, test boundary conditions, test boundary, boundary conditions, unit test. Use when: Use this pattern when planning or reviewing code where test just below, at, and just above important limits. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Test just below, at, and just above important limits.. Good TypeScript example: expect(canWithdraw(MINIMUM_WITHDRAWAL)).toBe(true); Good Python example: assert can_withdraw(MINIMUM_WITHDRAWAL) Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "assert can_withdraw(MINIMUM_WITHDRAWAL)", "typescript": "expect(canWithdraw(MINIMUM_WITHDRAWAL)).toBe(true);"}, "id": "CC-260", "lint_candidates": ["Test just below, at, and just above important limits."], "lintability": "high", "problem": "Code has a clean-code risk related to t5 test boundary conditions: Test just below, at, and just above important limits. Search terms that should match this issue include t5 test boundary conditions, test boundary conditions, test boundary, boundary conditions, unit test.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "T5 Test Boundary Conditions", "topic": "Tests", "use_when": "Use this pattern when planning or reviewing code where test just below, at, and just above important limits. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["t6 exhaustively test near bugs", "exhaustively test near bugs", "exhaustively test", "near bugs", "unit test", "test smell", "test design", "test quality", "tests", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-261 T6 Exhaustively Test Near Bugs\nTopic: Tests\nAliases: t6 exhaustively test near bugs, exhaustively test near bugs, exhaustively test, near bugs, unit test, test smell, test design, test quality, tests, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to t6 exhaustively test near bugs: When a bug appears, test nearby cases too. Search terms that should match this issue include t6 exhaustively test near bugs, exhaustively test near bugs, exhaustively test, near bugs, unit test.\nUse when: Use this pattern when planning or reviewing code where when a bug appears, test nearby cases too. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nexpect(parseDate('2026-02-29')).toThrow(InvalidDateError);\nGood Python:\nwith pytest.raises(InvalidDateError):\n    parse_date('2026-02-29')\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: When a bug appears, test nearby cases too.\nLintability: low", "embedding_text": "Clean code pattern CC-261: T6 Exhaustively Test Near Bugs. Topic: Tests. Rule family: tests. Aliases and smell terms: t6 exhaustively test near bugs, exhaustively test near bugs, exhaustively test, near bugs, unit test, test smell, test design, test quality, tests, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to t6 exhaustively test near bugs: When a bug appears, test nearby cases too. Search terms that should match this issue include t6 exhaustively test near bugs, exhaustively test near bugs, exhaustively test, near bugs, unit test. Use when: Use this pattern when planning or reviewing code where when a bug appears, test nearby cases too. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: When a bug appears, test nearby cases too.. Good TypeScript example: expect(parseDate('2026-02-29')).toThrow(InvalidDateError); Good Python example: with pytest.raises(InvalidDateError):\n    parse_date('2026-02-29') Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "with pytest.raises(InvalidDateError):\n    parse_date('2026-02-29')", "typescript": "expect(parseDate('2026-02-29')).toThrow(InvalidDateError);"}, "id": "CC-261", "lint_candidates": ["When a bug appears, test nearby cases too."], "lintability": "low", "problem": "Code has a clean-code risk related to t6 exhaustively test near bugs: When a bug appears, test nearby cases too. Search terms that should match this issue include t6 exhaustively test near bugs, exhaustively test near bugs, exhaustively test, near bugs, unit test.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "T6 Exhaustively Test Near Bugs", "topic": "Tests", "use_when": "Use this pattern when planning or reviewing code where when a bug appears, test nearby cases too. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["t7 failure patterns revealing", "failure patterns revealing", "failure patterns", "patterns revealing", "unit test", "test smell", "test design", "test quality", "tests", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-262 T7 Failure Patterns Revealing\nTopic: Tests\nAliases: t7 failure patterns revealing, failure patterns revealing, failure patterns, patterns revealing, unit test, test smell, test design, test quality, tests, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to t7 failure patterns revealing: Look for repeated failure shapes and add targeted tests. Search terms that should match this issue include t7 failure patterns revealing, failure patterns revealing, failure patterns, patterns revealing, unit test.\nUse when: Use this pattern when planning or reviewing code where look for repeated failure shapes and add targeted tests. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nexpect(() => parseAmount('1,00')).toThrow(InvalidAmountError);\nGood Python:\nwith pytest.raises(InvalidAmountError):\n    parse_amount('1,00')\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Look for repeated failure shapes and add targeted tests.\nLintability: low", "embedding_text": "Clean code pattern CC-262: T7 Failure Patterns Revealing. Topic: Tests. Rule family: tests. Aliases and smell terms: t7 failure patterns revealing, failure patterns revealing, failure patterns, patterns revealing, unit test, test smell, test design, test quality, tests, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to t7 failure patterns revealing: Look for repeated failure shapes and add targeted tests. Search terms that should match this issue include t7 failure patterns revealing, failure patterns revealing, failure patterns, patterns revealing, unit test. Use when: Use this pattern when planning or reviewing code where look for repeated failure shapes and add targeted tests. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Look for repeated failure shapes and add targeted tests.. Good TypeScript example: expect(() => parseAmount('1,00')).toThrow(InvalidAmountError); Good Python example: with pytest.raises(InvalidAmountError):\n    parse_amount('1,00') Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "with pytest.raises(InvalidAmountError):\n    parse_amount('1,00')", "typescript": "expect(() => parseAmount('1,00')).toThrow(InvalidAmountError);"}, "id": "CC-262", "lint_candidates": ["Look for repeated failure shapes and add targeted tests."], "lintability": "low", "problem": "Code has a clean-code risk related to t7 failure patterns revealing: Look for repeated failure shapes and add targeted tests. Search terms that should match this issue include t7 failure patterns revealing, failure patterns revealing, failure patterns, patterns revealing, unit test.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "T7 Failure Patterns Revealing", "topic": "Tests", "use_when": "Use this pattern when planning or reviewing code where look for repeated failure shapes and add targeted tests. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["t8 coverage patterns revealing", "coverage patterns revealing", "coverage patterns", "patterns revealing", "unit test", "test smell", "test design", "test quality", "tests", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-263 T8 Coverage Patterns Revealing\nTopic: Tests\nAliases: t8 coverage patterns revealing, coverage patterns revealing, coverage patterns, patterns revealing, unit test, test smell, test design, test quality, tests, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to t8 coverage patterns revealing: Use uncovered branches to find missing behavior examples. Search terms that should match this issue include t8 coverage patterns revealing, coverage patterns revealing, coverage patterns, patterns revealing, unit test.\nUse when: Use this pattern when planning or reviewing code where use uncovered branches to find missing behavior examples. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nexpect(discountFor(newCustomer)).toEqual(NO_DISCOUNT);\nGood Python:\nassert discount_for(new_customer) == NO_DISCOUNT\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Use uncovered branches to find missing behavior examples.\nLintability: high", "embedding_text": "Clean code pattern CC-263: T8 Coverage Patterns Revealing. Topic: Tests. Rule family: tests. Aliases and smell terms: t8 coverage patterns revealing, coverage patterns revealing, coverage patterns, patterns revealing, unit test, test smell, test design, test quality, tests, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to t8 coverage patterns revealing: Use uncovered branches to find missing behavior examples. Search terms that should match this issue include t8 coverage patterns revealing, coverage patterns revealing, coverage patterns, patterns revealing, unit test. Use when: Use this pattern when planning or reviewing code where use uncovered branches to find missing behavior examples. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Use uncovered branches to find missing behavior examples.. Good TypeScript example: expect(discountFor(newCustomer)).toEqual(NO_DISCOUNT); Good Python example: assert discount_for(new_customer) == NO_DISCOUNT Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "assert discount_for(new_customer) == NO_DISCOUNT", "typescript": "expect(discountFor(newCustomer)).toEqual(NO_DISCOUNT);"}, "id": "CC-263", "lint_candidates": ["Use uncovered branches to find missing behavior examples."], "lintability": "high", "problem": "Code has a clean-code risk related to t8 coverage patterns revealing: Use uncovered branches to find missing behavior examples. Search terms that should match this issue include t8 coverage patterns revealing, coverage patterns revealing, coverage patterns, patterns revealing, unit test.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "T8 Coverage Patterns Revealing", "topic": "Tests", "use_when": "Use this pattern when planning or reviewing code where use uncovered branches to find missing behavior examples. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}
+{"aliases": ["t9 tests should be fast", "tests should be fast", "tests should", "be fast", "unit test", "test smell", "test design", "test quality", "tests", "clean code", "code smell", "planning guidance"], "avoid_when": "Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.", "bad_examples": {"python": "def test_works():\n    assert a() == 1\n    assert b() == 2", "typescript": "it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });"}, "display_text": "CC-264 T9 Tests Should Be Fast\nTopic: Tests\nAliases: t9 tests should be fast, tests should be fast, tests should, be fast, unit test, test smell, test design, test quality, tests, clean code, code smell, planning guidance\nProblem: Code has a clean-code risk related to t9 tests should be fast: Keep unit tests quick enough to run continuously. Search terms that should match this issue include t9 tests should be fast, tests should be fast, tests should, be fast, unit test.\nUse when: Use this pattern when planning or reviewing code where keep unit tests quick enough to run continuously. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior.\nAvoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow.\nGood TypeScript:\nexpect(priceOrder(order)).toEqual(expectedTotal);\nGood Python:\nassert price_order(order) == expected_total\nBad TypeScript:\nit('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); });\nBad Python:\ndef test_works():\n    assert a() == 1\n    assert b() == 2\nLint candidates: Keep unit tests quick enough to run continuously.\nLintability: high", "embedding_text": "Clean code pattern CC-264: T9 Tests Should Be Fast. Topic: Tests. Rule family: tests. Aliases and smell terms: t9 tests should be fast, tests should be fast, tests should, be fast, unit test, test smell, test design, test quality, tests, clean code, code smell, planning guidance. Problem: Code has a clean-code risk related to t9 tests should be fast: Keep unit tests quick enough to run continuously. Search terms that should match this issue include t9 tests should be fast, tests should be fast, tests should, be fast, unit test. Use when: Use this pattern when planning or reviewing code where keep unit tests quick enough to run continuously. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior. Avoid when: Avoid applying this mechanically when an integration or characterization test intentionally covers a wider workflow. Lint candidates: Keep unit tests quick enough to run continuously.. Good TypeScript example: expect(priceOrder(order)).toEqual(expectedTotal); Good Python example: assert price_order(order) == expected_total Bad TypeScript example: it('works', () => { expect(a()).toBe(1); expect(b()).toBe(2); }); Bad Python example: def test_works():\n    assert a() == 1\n    assert b() == 2", "good_examples": {"python": "assert price_order(order) == expected_total", "typescript": "expect(priceOrder(order)).toEqual(expectedTotal);"}, "id": "CC-264", "lint_candidates": ["Keep unit tests quick enough to run continuously."], "lintability": "high", "problem": "Code has a clean-code risk related to t9 tests should be fast: Keep unit tests quick enough to run continuously. Search terms that should match this issue include t9 tests should be fast, tests should be fast, tests should, be fast, unit test.", "rule_family": "tests", "source": {"kind": "clean_code_original_example_enriched_from_markdown", "version": 1}, "title": "T9 Tests Should Be Fast", "topic": "Tests", "use_when": "Use this pattern when planning or reviewing code where keep unit tests quick enough to run continuously. It is especially relevant when tests are hard to read, flaky, broad, slow, or missing boundary behavior."}