@jwikman/bc-code-intelligence-mcp 1.5.7-dev.1

package/embedded-knowledge/domains/roger-reviewer/samples/lonely-repeat-examples.md

@@ -0,0 +1,280 @@
+# Lonely Repeat Statement Pattern - AL Code Examples
+
+## Overview
+The "Lonely Repeat Statement Pattern" refers to repeat-until loops that are difficult to read due to poor formatting, unclear conditions, or lack of proper structure. This sample demonstrates how to identify and fix these patterns in AL code.
+
+## Problem Pattern: Lonely and Hard-to-Read Repeat Statements
+
+### Example 1: Basic Formatting Issues
+
+**Problematic Code:**
+```al
+procedure ProcessCustomerRecords()
+var
+    Customer: Record Customer;
+    Counter: Integer;
+begin
+    Customer.FindFirst();
+    repeat Customer.CalcFields("Sales (LCY)"); if Customer."Sales (LCY)" > 10000 then begin Counter += 1; Message('High value customer: %1', Customer.Name); end; until Customer.Next() = 0;
+end;
+```
+
+**Improved Code:**
+```al
+procedure ProcessCustomerRecords()
+var
+    Customer: Record Customer;
+    Counter: Integer;
+begin
+    if Customer.FindFirst() then
+        repeat
+            Customer.CalcFields("Sales (LCY)");
+            if Customer."Sales (LCY)" > 10000 then begin
+                Counter += 1;
+                Message('High value customer: %1', Customer.Name);
+            end;
+        until Customer.Next() = 0;
+end;
+```
+
+### Example 2: Complex Condition Handling
+
+**Problematic Code:**
+```al
+procedure ValidateItemInventory()
+var
+    Item: Record Item;
+    InventorySetup: Record "Inventory Setup";
+    IsValid: Boolean;
+begin
+    Item.SetRange(Blocked, false);
+    Item.FindFirst();
+    repeat IsValid := true; Item.CalcFields(Inventory); if (Item.Inventory < Item."Reorder Point") and (Item."Reorder Point" > 0) and (Item."Replenishment System" = Item."Replenishment System"::Purchase) then IsValid := false; if not IsValid then Error('Item %1 needs reordering', Item."No."); until Item.Next() = 0;
+end;
+```
+
+**Improved Code:**
+```al
+procedure ValidateItemInventory()
+var
+    Item: Record Item;
+    NeedsReordering: Boolean;
+begin
+    Item.SetRange(Blocked, false);
+    if Item.FindFirst() then
+        repeat
+            Item.CalcFields(Inventory);
+
+            NeedsReordering := (Item.Inventory < Item."Reorder Point") and
+                              (Item."Reorder Point" > 0) and
+                              (Item."Replenishment System" = Item."Replenishment System"::Purchase);
+
+            if NeedsReordering then
+                Error('Item %1 needs reordering', Item."No.");
+        until Item.Next() = 0;
+end;
+```
+
+## Advanced Pattern Improvements
+
+### Example 3: Nested Loop Clarity
+
+**Problematic Code:**
+```al
+procedure RecalculateCustomerStatistics()
+var
+    Customer: Record Customer;
+    SalesLine: Record "Sales Line";
+    TotalAmount: Decimal;
+begin
+    Customer.FindFirst();
+    repeat TotalAmount := 0; SalesLine.SetRange("Sell-to Customer No.", Customer."No."); if SalesLine.FindFirst() then repeat TotalAmount += SalesLine."Line Amount"; until SalesLine.Next() = 0; Customer."Sales (LCY)" := TotalAmount; Customer.Modify(); until Customer.Next() = 0;
+end;
+```
+
+**Improved Code:**
+```al
+procedure RecalculateCustomerStatistics()
+var
+    Customer: Record Customer;
+    SalesLine: Record "Sales Line";
+    TotalAmount: Decimal;
+begin
+    if Customer.FindFirst() then
+        repeat
+            TotalAmount := 0;
+            SalesLine.SetRange("Sell-to Customer No.", Customer."No.");
+
+            if SalesLine.FindFirst() then
+                repeat
+                    TotalAmount += SalesLine."Line Amount";
+                until SalesLine.Next() = 0;
+
+            Customer."Sales (LCY)" := TotalAmount;
+            Customer.Modify();
+        until Customer.Next() = 0;
+end;
+```
+
+### Example 4: Error Handling in Repeat Loops
+
+**Problematic Code:**
+```al
+procedure PostSalesDocuments()
+var
+    SalesHeader: Record "Sales Header";
+    SalesPost: Codeunit "Sales-Post";
+begin
+    SalesHeader.SetRange("Document Type", SalesHeader."Document Type"::Order);
+    SalesHeader.SetRange(Status, SalesHeader.Status::Released);
+    SalesHeader.FindFirst();
+    repeat if not SalesPost.Run(SalesHeader) then Message('Error posting document %1', SalesHeader."No."); until SalesHeader.Next() = 0;
+end;
+```
+
+**Improved Code:**
+```al
+procedure PostSalesDocuments()
+var
+    SalesHeader: Record "Sales Header";
+    SalesPost: Codeunit "Sales-Post";
+    DocumentsProcessed: Integer;
+    DocumentsFailed: Integer;
+begin
+    SalesHeader.SetRange("Document Type", SalesHeader."Document Type"::Order);
+    SalesHeader.SetRange(Status, SalesHeader.Status::Released);
+
+    if SalesHeader.FindFirst() then
+        repeat
+            Clear(SalesPost);
+            if SalesPost.Run(SalesHeader) then
+                DocumentsProcessed += 1
+            else begin
+                DocumentsFailed += 1;
+                Message('Error posting document %1: %2', SalesHeader."No.", GetLastErrorText());
+            end;
+        until SalesHeader.Next() = 0;
+
+    Message('Processing complete. Posted: %1, Failed: %2', DocumentsProcessed, DocumentsFailed);
+end;
+```
+
+## Performance and Safety Patterns
+
+### Example 5: Large Dataset Processing
+
+**Problematic Code:**
+```al
+procedure ArchiveOldEntries()
+var
+    GLEntry: Record "G/L Entry";
+    ArchiveEntry: Record "G/L Entry Archive";
+begin
+    GLEntry.SetFilter("Posting Date", '<%1', CalcDate('-2Y', Today()));
+    GLEntry.FindFirst();
+    repeat ArchiveEntry.TransferFields(GLEntry); ArchiveEntry.Insert(); GLEntry.Delete(); until GLEntry.Next() = 0;
+end;
+```
+
+**Improved Code:**
+```al
+procedure ArchiveOldEntries()
+var
+    GLEntry: Record "G/L Entry";
+    ArchiveEntry: Record "G/L Entry Archive";
+    ProcessedCount: Integer;
+    BatchSize: Integer;
+begin
+    BatchSize := 1000; // Process in batches for better performance
+    ProcessedCount := 0;
+
+    GLEntry.SetFilter("Posting Date", '<%1', CalcDate('-2Y', Today()));
+
+    if GLEntry.FindFirst() then
+        repeat
+            ArchiveEntry.TransferFields(GLEntry);
+            ArchiveEntry.Insert();
+            GLEntry.Delete();
+
+            ProcessedCount += 1;
+
+            // Commit periodically to avoid long transactions
+            if ProcessedCount mod BatchSize = 0 then begin
+                Commit();
+                Message('Processed %1 entries...', ProcessedCount);
+            end;
+        until GLEntry.Next() = 0;
+
+    Message('Archive complete. Total entries processed: %1', ProcessedCount);
+end;
+```
+
+### Example 6: Conditional Processing with Early Exit
+
+**Problematic Code:**
+```al
+procedure FindFirstAvailableItem(LocationCode: Code[10]): Code[20]
+var
+    Item: Record Item;
+    ItemLedgerEntry: Record "Item Ledger Entry";
+    AvailableQty: Decimal;
+begin
+    Item.FindFirst();
+    repeat Item.SetRange("Location Filter", LocationCode); Item.CalcFields(Inventory); if Item.Inventory > 0 then exit(Item."No."); until Item.Next() = 0;
+end;
+```
+
+**Improved Code:**
+```al
+procedure FindFirstAvailableItem(LocationCode: Code[10]): Code[20]
+var
+    Item: Record Item;
+begin
+    Item.SetRange(Blocked, false);
+    Item.SetRange(Type, Item.Type::Inventory);
+
+    if Item.FindFirst() then
+        repeat
+            Item.SetRange("Location Filter", LocationCode);
+            Item.CalcFields(Inventory);
+
+            if Item.Inventory > 0 then
+                exit(Item."No.");
+        until Item.Next() = 0;
+
+    // Return empty if no available item found
+    exit('');
+end;
+```
+
+## Best Practices Summary
+
+### Formatting Guidelines
+1. **Always use proper indentation** for repeat-until blocks
+2. **Place conditions on separate lines** for complex boolean expressions
+3. **Use meaningful variable names** instead of inline calculations
+4. **Add blank lines** to separate logical sections within loops
+
+### Performance Considerations
+1. **Process in batches** for large datasets to avoid transaction timeouts
+2. **Use proper filters** before starting repeat loops to minimize iterations
+3. **Calculate fields only when necessary** within the loop
+4. **Consider using FindSet()** with ReadOnly parameter for read-only operations
+
+### Error Handling
+1. **Always check FindFirst() result** before starting repeat loop
+2. **Handle errors gracefully** with appropriate user feedback
+3. **Use Clear()** on codeunit variables before calling Run()
+4. **Implement progress indicators** for long-running operations
+
+### Code Readability
+1. **Extract complex conditions** into well-named boolean variables
+2. **Use early exit patterns** when searching for specific records
+3. **Add comments** to explain business logic within loops
+4. **Avoid deeply nested structures** by using helper procedures
+
+## Related Patterns
+- **FindSet Pattern**: Use `FindSet()` with `ReadOnly` parameter for better performance when only reading data
+- **Batch Processing Pattern**: Process records in controlled batches with periodic commits
+- **Error Accumulation Pattern**: Collect errors during processing and report them together
+- **Progress Indication Pattern**: Provide user feedback during long-running repeat operations

package/embedded-knowledge/domains/roger-reviewer/samples/testability-code-smells.md

@@ -0,0 +1,256 @@
+# Testability Code Smell Examples
+
+## Code Smell #1: Direct BC Table Access
+
+### ❌ Problematic Code
+```al
+procedure CalculateCustomerDiscount(CustomerNo: Code[20]; Amount: Decimal): Decimal
+var
+    Customer: Record Customer;
+    CustomerPriceGroup: Record "Customer Price Group";
+    DiscountPct: Decimal;
+begin
+    // Direct access to BC tables
+    Customer.Get(CustomerNo);
+    Customer.TestField("Customer Price Group");
+    
+    CustomerPriceGroup.Get(Customer."Customer Price Group");
+    DiscountPct := CustomerPriceGroup."Discount %";
+    
+    if Customer."Allow Line Disc." then
+        DiscountPct += 5;
+        
+    exit(Amount * DiscountPct / 100);
+end;
+```
+
+### Why It's Problematic
+To test this, you need:
+- A Customer record with specific fields populated
+- A Customer Price Group record
+- Proper relationships between them
+
+Test becomes:
+```al
+[Test]
+procedure Test_CustomerDiscount()
+begin
+    // [GIVEN] Customer with price group
+    LibrarySales.CreateCustomer(Customer);
+    Customer."Allow Line Disc." := true;
+    Customer.Modify();
+    
+    // [GIVEN] Price group with discount
+    CreateCustomerPriceGroup(PriceGroup);
+    PriceGroup."Discount %" := 10;
+    PriceGroup.Modify();
+    
+    Customer."Customer Price Group" := PriceGroup.Code;
+    Customer.Modify();
+    
+    // You're testing BC table relationships, not your discount logic!
+```
+
+### ✅ Better: Separate Data Access from Logic
+```al
+// Interface for getting discount configuration
+interface IDiscountConfiguration
+{
+    procedure GetBaseDiscount(CustomerNo: Code[20]): Decimal;
+    procedure AllowsLineDiscount(CustomerNo: Code[20]): Boolean;
+}
+
+// Business logic - testable
+procedure CalculateDiscount(Amount: Decimal; BaseDiscount: Decimal; AllowLineDiscount: Boolean): Decimal
+var
+    TotalDiscount: Decimal;
+begin
+    TotalDiscount := BaseDiscount;
+    if AllowLineDiscount then
+        TotalDiscount += 5;
+    exit(Amount * TotalDiscount / 100);
+end;
+```
+
+---
+
+## Code Smell #2: Tests Full of Unrelated GIVENs
+
+### ❌ Problematic Test
+```al
+[Test]
+procedure Test_CalculateShippingCost()
+var
+    Customer: Record Customer;
+    Item: Record Item;
+    SalesHeader: Record "Sales Header";
+    SalesLine: Record "Sales Line";
+    ShippingAgent: Record "Shipping Agent";
+    ShippingService: Record "Shipping Agent Services";
+begin
+    // [GIVEN] Customer  
+    LibrarySales.CreateCustomer(Customer);
+    
+    // [GIVEN] Shipping Agent with service
+    LibraryInventory.CreateShippingAgent(ShippingAgent);
+    LibraryInventory.CreateShippingAgentService(ShippingAgent.Code, ShippingService);
+    ShippingService."Shipping Cost" := 10;
+    ShippingService.Modify();
+    
+    // [GIVEN] Item with weight
+    LibraryInventory.CreateItem(Item);
+    Item."Gross Weight" := 5;
+    Item.Modify();
+    
+    // [GIVEN] Sales Order
+    LibrarySales.CreateSalesHeader(SalesHeader, SalesHeader."Document Type"::Order, Customer."No.");
+    SalesHeader."Shipping Agent Code" := ShippingAgent.Code;
+    SalesHeader."Shipping Agent Service Code" := ShippingService.Code;
+    SalesHeader.Modify();
+    
+    // [GIVEN] Sales Line
+    LibrarySales.CreateSalesLine(SalesLine, SalesHeader, SalesLine.Type::Item, Item."No.", 10);
+    
+    // [WHEN] Calculate shipping
+    ShippingCalculator.Calculate(SalesHeader);
+    
+    // [THEN] Cost is correct
+    SalesHeader.Find();
+    Assert.AreEqual(50, SalesHeader."Shipping Cost", 'Expected 5kg * 10 units * $1/kg');
+end;
+```
+
+### Why It's Problematic
+- 25 lines of GIVEN for 2 lines of WHEN/THEN
+- Most GIVENs satisfy BC table requirements, not business logic
+- If BC changes Customer or Item structure, test breaks
+- Slow due to database operations
+
+### ✅ Better: Test the Calculation Directly
+```al
+[Test]
+procedure Test_CalculateShippingCost()
+var
+    Calculator: Codeunit "Shipping Calculator";
+    Weight: Decimal;
+    CostPerKg: Decimal;
+    ExpectedCost: Decimal;
+begin
+    // [GIVEN] Known weight and cost rate
+    Weight := 50;  // 5kg * 10 units
+    CostPerKg := 1;
+    
+    // [WHEN] Calculate shipping cost
+    ActualCost := Calculator.CalculateCost(Weight, CostPerKg);
+    
+    // [THEN] Cost is weight * rate
+    Assert.AreEqual(50, ActualCost, 'Weight * CostPerKg');
+end;
+```
+
+---
+
+## Code Smell #3: Assertions Testing BC Behavior
+
+### ❌ Problematic Test
+```al
+[Test]
+procedure Test_CurrencyConversion()
+begin
+    // [GIVEN] Currencies and exchange rates
+    LibraryERM.CreateCurrency(FromCurrency);
+    LibraryERM.CreateCurrency(ToCurrency);
+    LibraryERM.CreateExchangeRate(FromCurrency.Code, WorkDate(), 10, 10);
+    LibraryERM.CreateExchangeRate(ToCurrency.Code, WorkDate(), 0.1, 0.1);
+    
+    // [WHEN] Convert 1 unit
+    Amount := Converter.Convert(1, FromCurrency.Code, ToCurrency.Code);
+    
+    // [THEN] Amount is converted correctly
+    Assert.AreEqual(0.01, Amount, 'Conversion incorrect');
+    // ^^^ Do you even know WHY this should be 0.01?
+end;
+```
+
+### Why It's Problematic
+- The expected value (0.01) comes from BC's calculation, not your knowledge
+- You're testing BC's exchange rate math, not your code
+- If BC changes rounding rules, your test breaks (but your code might be fine)
+
+### ✅ Better: Use a Stub with Known Values
+```al
+[Test]
+procedure Test_ConversionProcessFlow()
+var
+    StubConverter: Codeunit "Stub Currency Converter";
+    SpyLogger: Codeunit "Spy Logger";
+begin
+    // [GIVEN] Converter that returns known value
+    StubConverter.SetReturnValue(42);
+    
+    // [WHEN] Conversion performed
+    Amount := MyProcess.Convert(100, 'USD', 'EUR', StubConverter, SpyLogger);
+    
+    // [THEN] Process returns converter's result
+    Assert.AreEqual(42, Amount, 'Should return converter result');
+    
+    // [THEN] Logger captured correct input
+    Assert.AreEqual(100, SpyLogger.GetCapturedInputAmount(), 'Input logged');
+end;
+```
+
+---
+
+## Code Smell #4: DeleteAll in Test Setup
+
+### ❌ Problematic Test
+```al
+[Test]
+procedure Test_CreateLogEntry()
+var
+    IntegrationLog: Record "Integration Log";
+begin
+    // [GIVEN] No existing entries
+    IntegrationLog.DeleteAll();  // ❌ Modifying shared state
+    
+    // [WHEN] Process runs
+    IntegrationProcess.Run();
+    
+    // [THEN] One entry created
+    Assert.AreEqual(1, IntegrationLog.Count(), 'Expected one entry');
+end;
+```
+
+### Why It's Problematic
+- Modifies database state that other tests might depend on
+- "No existing entries" is NOT a realistic business scenario
+- Test depends on counting records, not verifying behavior
+
+### ✅ Better: Use a Spy Logger
+```al
+[Test]
+procedure Test_ProcessLogsExecution()
+var
+    SpyLogger: Codeunit "Spy Logger";
+begin
+    // [WHEN] Process runs with spy logger
+    IntegrationProcess.Run(SpyLogger);
+    
+    // [THEN] Logger was invoked
+    Assert.IsTrue(SpyLogger.WasInvoked(), 'Should log execution');
+    Assert.AreEqual('IntegrationProcess', SpyLogger.GetLastOperation(), 'Operation name');
+end;
+```
+
+---
+
+## Quick Reference: Smells and Fixes
+
+| Smell | Symptom | Fix |
+|-------|---------|-----|
+| Direct BC table access | Can't test without database | Interface abstraction |
+| Too many GIVENs | Test setup >> test logic | Dependency injection |
+| Asserting BC values | You calculated expected from BC | Stub with known values |
+| DeleteAll in setup | Cleaning shared state | Spy/Mock instead |
+| Setup switch | `case Setup.Type of` | Interface polymorphism |
+| Mixed data + logic | Single proc does both | Separate into layers |

package/embedded-knowledge/domains/roger-reviewer/testability-code-smells.md

@@ -0,0 +1,67 @@
+---
+title: "Testability Code Smells"
+domain: "roger-reviewer"
+difficulty: "intermediate"
+bc_versions: "18+"
+tags: ["code-review", "testability", "code-smells", "tight-coupling", "dependencies"]
+samples: "samples/testability-code-smells.md"
+related_topics:
+  - "../alex-architect/testability-design-patterns.md"
+  - "../quinn-tester/isolation-testing-patterns.md"
+source: "Adapted from Vjeko.com: Testing in isolation (Dec 2023)"
+---
+# Testability Code Smells
+
+## Overview
+
+Code that cannot be tested in isolation has recognizable patterns—"code smells" that indicate tight coupling. Identifying these during review catches testability issues before they become embedded.
+
+**Core Principle**: If testing requires extensive database setup unrelated to the code's purpose, that code has testability problems.
+
+## Code Smell #1: Direct BC Table Access in Business Logic
+
+Business logic directly references BC base app or system tables. Testing requires creating those records—you're testing BC's table structure, not your logic.
+
+## Code Smell #2: Hardcoded External Service Calls
+
+HTTP clients, file operations, or external services directly in business logic. Cannot test without network access; tests hit real systems; flaky due to availability.
+
+## Code Smell #3: Tests Full of Unrelated GIVENs
+
+Test setup creates data the business logic doesn't directly need. Most GIVENs exist to satisfy BC dependencies, not your logic. Test obscures what's actually being tested.
+
+## Code Smell #4: Assertions Testing BC Behavior
+
+Test assertions validate BC functionality rather than custom logic. You don't know if the expected value is correct—you're trusting BC's calculation.
+
+## Code Smell #5: Setup Switch Instead of Abstraction
+
+Configuration-driven branching between implementations (`case Setup.Type of`). Business logic knows about all implementations; adding new ones requires modifying logic. This is MORE coupling, not less.
+
+## Code Smell #6: DeleteAll in Test Setup
+
+Tests that clean tables to ensure predictable state. Modifies shared state; "no entries" isn't a realistic GIVEN; indicates coupling to storage, not logic.
+
+## Code Smell #7: Mixed Data Access and Business Logic
+
+Single procedure that retrieves data AND processes it. Cannot test logic without database; cannot test with specific edge cases.
+
+## Quick Review Checklist
+
+| Question | If Yes → |
+|----------|----------|
+| Does business logic directly access BC tables? | Consider abstraction |
+| Does it call external services directly? | Wrap in interface |
+| Would testing require unrelated BC records? | Dependencies too tight |
+| Are tests asserting BC behavior? | Missing test doubles |
+| Does a switch select implementations? | Use interface instead |
+| Do tests DeleteAll before running? | Test coupled to storage |
+
+## Handoff Guidance
+
+- **Architectural redesign** → Alex Architect
+- **Implementing test doubles** → Quinn Tester
+- **Interface design patterns** → Alex Architect
+
+See samples for code examples of each smell and its fix.
+

package/embedded-knowledge/domains/sam-coder/al-formatting-consistency-patterns.md

@@ -0,0 +1,75 @@
+---
+title: "AL Formatting Consistency Patterns"
+domain: "sam-coder"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["formatting", "consistency", "code-standards"]
+type: "improvement-pattern"
+category: "code-quality"
+pattern_type: "good"
+severity: "medium"
+impact_level: "medium"
+improvement_suggestion: "Apply consistent formatting patterns across all AL code to improve maintainability"
+implementation_steps: ["establish-formatting-standards", "apply-consistent-patterns", "validate-uniformity"]
+validation_criteria: ["consistent-formatting-application", "improved-code-uniformity"]
+technical_areas: ["al-code"]
+---
+
+# AL Formatting Consistency Patterns
+
+## Overview
+
+Consistent formatting patterns across AL code improve maintainability, reduce cognitive load, and enhance team collaboration. Establishing and applying uniform formatting standards creates professional, readable code that supports effective development workflows.
+
+**Key Principle**: Apply consistent formatting patterns uniformly across all AL objects to create predictable, maintainable code structure.
+
+## Strategic Framework
+
+### Consistency Benefits
+- **Reduced Cognitive Load**: Predictable formatting reduces mental effort
+- **Improved Collaboration**: Team members can focus on logic rather than style
+- **Enhanced Maintainability**: Consistent patterns support easier code updates
+- **Professional Quality**: Uniform appearance reflects development maturity
+
+### Code Quality Impact
+Consistent formatting directly impacts code quality by making code easier to read, review, and maintain. It supports effective development practices and reduces errors.
+
+## Architecture Focus
+
+### Formatting Domains
+- **Indentation Standards**: Consistent spacing and alignment patterns
+- **Keyword Formatting**: Uniform keyword placement and casing
+- **Comment Styles**: Standardized documentation formatting
+- **Expression Layout**: Consistent operator and expression formatting
+
+### Pattern Application
+Establish comprehensive formatting standards that cover all aspects of AL code appearance and apply them consistently across entire codebase.
+
+## Best Practices
+
+### Standards Development
+- **Comprehensive guidelines** covering all AL language elements
+- **Team agreement** on formatting preferences and standards
+- **Tool integration** for automated formatting enforcement
+- **Regular validation** of consistency across codebase
+- **Documentation** of formatting decisions and rationale
+
+### Implementation Strategy
+Use automated formatting tools where possible, establish clear team guidelines for manual formatting decisions, and regularly review code for consistency compliance.
+
+### Maintenance Approach
+Integrate formatting standards into development workflow through code review processes, automated validation, and team training on consistency importance.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Mixed formatting styles** within single project
+- **Inconsistent indentation** across AL objects
+- **Random keyword casing** without standards
+- **Varied comment formatting** creating visual inconsistency
+- **No formatting guidelines** leading to style conflicts
+
+Inconsistent formatting creates unnecessary cognitive overhead and makes code harder to maintain and review effectively.
+
+*Related patterns: al-readability-optimization.md, al-blank-line-organization.md*
+*Cross-references: See samples in other formatting topics for consistency examples*