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

package/embedded-knowledge/domains/roger-reviewer/al-code-spacing-conventions.md

@@ -0,0 +1,81 @@
+---
+title: "AL Code Spacing and Indentation Conventions"
+domain: "roger-reviewer"
+difficulty: "beginner"
+bc_versions: "14+"
+tags: ["formatting", "indentation", "code-style", "readability"]
+prerequisites: ["al-syntax"]
+---
+# AL Code Spacing and Indentation Conventions
+
+## Overview
+
+Consistent spacing and indentation in AL code improves readability, reduces cognitive load, and enables better collaboration across development teams. Following established conventions ensures code maintainability and professional appearance.
+
+**Foundation Principle**: Use consistent 4-space indentation throughout AL code with strategic white space to enhance logical grouping and flow comprehension.
+
+## Strategic Framework
+
+### Indentation Standards
+- **4-space indentation**: Standard for AL code blocks and nested structures
+- **No mixed tabs/spaces**: Consistent space-only indentation
+- **Logical nesting**: Each nested level increases indentation by 4 spaces
+- **Alignment consistency**: Maintain alignment patterns within code sections
+
+### White Space Strategy
+- **Logical grouping**: Separate related code blocks with blank lines
+- **Operator spacing**: Consistent spacing around operators and assignments
+- **Parameter formatting**: Clear spacing in procedure calls and definitions
+- **Object boundaries**: Appropriate spacing between object sections
+
+## Architecture Patterns
+
+### Object Structure Spacing
+Organize object definitions with consistent spacing between properties, fields, and procedures. Use blank lines to separate logical sections within objects.
+
+### Procedure Formatting
+Structure procedure definitions with proper spacing around parameters, local variables, and code blocks. Maintain consistent patterns for procedure calls and nested logic.
+
+### Expression and Statement Spacing
+Apply consistent spacing around operators, assignment statements, and conditional expressions to enhance readability and reduce parsing errors.
+
+## Implementation Guidelines
+
+### Standard Patterns
+- **Variable declarations**: Group related variables with consistent spacing
+- **Control structures**: Proper spacing around if/then/else, for loops, and case statements
+- **Object references**: Consistent spacing in field references and procedure calls
+- **Multi-line statements**: Logical line breaks with appropriate continuation indentation
+
+### Special Formatting Cases
+- **Long parameter lists**: Break parameters across lines with consistent indentation
+- **Complex expressions**: Use spacing and line breaks to clarify operator precedence
+- **Nested structures**: Maintain clear indentation hierarchy in complex logic
+- **String concatenation**: Clear spacing around concatenation operators
+
+## Best Practices
+
+### Consistency Standards
+- **Team conventions**: Establish and maintain team-wide formatting standards
+- **Automated formatting**: Use AL formatter tools to ensure consistency
+- **Code reviews**: Include formatting checks in review processes
+- **Documentation**: Maintain formatting guidelines for team reference
+
+### Readability Optimization
+- **Logical grouping**: Use white space to show code organization
+- **Visual hierarchy**: Indentation reflects logical code structure
+- **Scanning efficiency**: Format code for quick visual parsing
+- **Error reduction**: Clear formatting reduces misreading and mistakes
+
+### Tool Integration
+Configure development environments to automatically apply consistent formatting. Use linting tools to enforce spacing conventions across the codebase.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Inconsistent indentation**: Mixed spaces, tabs, or varying indent levels
+- **Excessive blank lines**: Too much white space that breaks code flow
+- **Cramped formatting**: Insufficient spacing that reduces readability
+- **Misaligned parameters**: Inconsistent parameter formatting across procedures
+- **Ignored formatting tools**: Manual formatting instead of automated tools
+

package/embedded-knowledge/domains/roger-reviewer/al-comment-spacing-standards.md

@@ -0,0 +1,76 @@
+---
+title: "AL Comment Spacing Standards"
+domain: "roger-reviewer"
+difficulty: "beginner"
+bc_versions: "14+"
+tags: ["comments", "documentation", "spacing"]
+samples: "samples/al-comment-spacing-standards.md"
+type: "improvement-pattern"
+category: "code-formatting"
+pattern_type: "good"
+severity: "medium"
+impact_level: "medium"
+improvement_suggestion: "Apply consistent spacing around AL comments to improve readability and documentation clarity"
+implementation_steps: ["standardize-comment-spacing", "apply-consistent-patterns", "validate-readability"]
+validation_criteria: ["consistent-comment-spacing", "clear-documentation-separation"]
+technical_areas: ["al-code"]
+---
+
+# AL Comment Spacing Standards
+
+## Overview
+
+Consistent spacing around AL comments improves code readability and ensures documentation integrates smoothly with code structure. Proper comment spacing helps developers distinguish between code and documentation while maintaining clean visual organization.
+
+**Key Principle**: Use consistent spacing patterns around comments to create clear separation between documentation and executable code.
+
+## Strategic Framework
+
+### Documentation Integration
+- **Visual Separation**: Clear spacing between comments and code elements
+- **Consistency Patterns**: Uniform spacing application across all AL objects
+- **Readability Focus**: Spacing that enhances documentation effectiveness
+- **Code Organization**: Comments as integral part of code structure
+
+### Communication Enhancement
+Well-spaced comments improve developer communication by making documentation more accessible and visually integrated with code logic.
+
+## Architecture Focus
+
+### Comment Types
+- **Line Comments**: Single-line documentation with appropriate spacing
+- **Block Comments**: Multi-line documentation with consistent formatting
+- **Inline Comments**: End-of-line explanations with proper separation
+- **Section Headers**: Major section documentation with clear boundaries
+
+### Spacing Patterns
+Establish consistent spacing rules that work well with AL syntax highlighting and support effective documentation practices within development teams.
+
+## Best Practices
+
+### Spacing Guidelines
+- **Blank line before** major comment blocks
+- **Single space after** comment delimiters (//)
+- **Consistent indentation** for comment content alignment
+- **Appropriate separation** between comments and related code
+- **Clear boundaries** around documentation sections
+
+### Comment Organization
+Group related comments effectively, maintain consistent formatting within comment blocks, and use spacing to create logical documentation structure.
+
+### Integration with Code
+Position comments to enhance code understanding without disrupting visual code flow. Use spacing to create natural reading rhythm between documentation and implementation.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Inconsistent spacing** around comment delimiters
+- **Cramped comments** without adequate separation from code
+- **Excessive spacing** that fragments code unnecessarily
+- **Poor indentation** in multi-line comment blocks
+- **Random comment placement** without logical organization
+
+Poor comment spacing makes documentation harder to read and reduces the effectiveness of code documentation efforts.
+
+*Implementation examples: see samples/al-comment-spacing-standards.md*
+*Related patterns: al-blank-line-organization.md, al-readability-optimization.md*

package/embedded-knowledge/domains/roger-reviewer/al-end-else-pairing.md

@@ -0,0 +1,75 @@
+---
+title: "AL End Else Pairing"
+domain: "roger-reviewer"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["end-statements", "else-clauses", "block-structure"]
+type: "improvement-pattern"
+category: "language-fundamentals"
+pattern_type: "good"
+severity: "medium"
+impact_level: "medium"
+improvement_suggestion: "Properly pair end statements with else clauses to maintain clear block structure"
+implementation_steps: ["identify-block-boundaries", "align-end-else-pairs", "validate-structure"]
+validation_criteria: ["correct-end-else-pairing", "clear-block-boundaries"]
+technical_areas: ["al-code"]
+---
+
+# AL End Else Pairing
+
+## Overview
+
+Proper pairing of end statements with else clauses in AL code maintains clear block structure and prevents syntax errors. Understanding end-else relationships is crucial for writing maintainable conditional logic and avoiding common AL language pitfalls.
+
+**Key Principle**: Each end statement must properly close its corresponding block before any related else clause can be processed.
+
+## Strategic Framework
+
+### Block Structure Integrity
+- **Scope Management**: Clear understanding of block boundaries and closure
+- **Syntax Correctness**: Proper AL language structure compliance
+- **Error Prevention**: Avoiding common end-else pairing mistakes
+- **Code Clarity**: Structure that makes block relationships obvious
+
+### Language Compliance
+AL language requires specific patterns for end-else pairing that differ from some other programming languages. Understanding these patterns prevents compilation errors and logic mistakes.
+
+## Architecture Focus
+
+### Pairing Patterns
+- **Conditional Blocks**: Proper end placement before else statements
+- **Nested Structures**: Correct pairing in complex conditional hierarchies
+- **Block Boundaries**: Clear indication of scope closure points
+- **Statement Organization**: Logical grouping of related conditional elements
+
+### Syntax Requirements
+AL syntax requires end statements to properly close conditional blocks before else clauses can be evaluated. This pattern ensures clear logical flow and prevents ambiguous code interpretation.
+
+## Best Practices
+
+### Correct Pairing Techniques
+- **Close blocks completely** before else statements
+- **Align end-else pairs** for visual clarity
+- **Use consistent indentation** to show block relationships
+- **Validate block closure** before adding else clauses
+- **Structure complex conditionals** with clear pairing patterns
+
+### Error Prevention
+Understand AL language requirements for end-else pairing to avoid compilation errors. Use proper formatting to make block relationships immediately apparent to code reviewers.
+
+### Code Organization
+Structure conditional logic with clear end-else pairing that supports easy understanding of decision flow and block boundaries.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Missing end statements** before else clauses
+- **Improper block closure** creating syntax errors
+- **Ambiguous pairing** in nested conditional structures
+- **Poor indentation** obscuring block relationships
+- **Complex nesting** without clear pairing patterns
+
+Incorrect end-else pairing creates compilation errors and makes conditional logic difficult to understand and maintain.
+
+*Related patterns: al-separate-if-else-formatting.md, al-keyword-indentation-rules.md*
+*See also: al-separate-if-else-formatting.md samples for practical examples*

package/embedded-knowledge/domains/roger-reviewer/al-keyword-indentation-rules.md

@@ -0,0 +1,76 @@
+---
+title: "AL Keyword Indentation Rules"
+domain: "roger-reviewer"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["indentation", "keywords", "code-structure"]
+samples: "samples/al-keyword-indentation-rules.md"
+type: "improvement-pattern"
+category: "code-formatting"
+pattern_type: "good"
+severity: "medium"
+impact_level: "medium"
+improvement_suggestion: "Apply consistent indentation rules for AL keywords to create clear code hierarchy"
+implementation_steps: ["define-indentation-standards", "apply-keyword-rules", "validate-consistency"]
+validation_criteria: ["consistent-keyword-indentation", "clear-code-hierarchy"]
+technical_areas: ["al-code"]
+---
+
+# AL Keyword Indentation Rules
+
+## Overview
+
+Consistent indentation rules for AL keywords create clear visual hierarchy in code structure, making it easier to understand control flow, scope boundaries, and logical organization. Proper keyword indentation is fundamental to readable and maintainable AL code.
+
+**Key Principle**: Keywords should follow consistent indentation patterns that reflect code structure and logical hierarchy.
+
+## Strategic Framework
+
+### Indentation Hierarchy
+- **Block Structure**: Keywords reflect nesting levels and scope boundaries
+- **Visual Clarity**: Indentation immediately shows code organization
+- **Consistency Standards**: Uniform application across all AL objects
+- **Readability Focus**: Indentation supports quick code comprehension
+
+### Code Structure Reflection
+Keyword indentation should mirror the logical structure of AL code, making scope boundaries and control flow patterns immediately visible to developers.
+
+## Architecture Focus
+
+### Keyword Categories
+- **Control Flow Keywords**: if, else, while, for, case statements
+- **Block Delimiters**: begin, end pairs and scope boundaries
+- **Declaration Keywords**: var, procedure, trigger declarations
+- **Object Keywords**: table, page, codeunit structure elements
+
+### Hierarchy Patterns
+Establish clear indentation increments that consistently reflect nesting levels and logical code organization. Standard indentation helps teams maintain consistent code appearance.
+
+## Best Practices
+
+### Indentation Standards
+- **Consistent increment size** (typically 4 spaces) for each nesting level
+- **Aligned block keywords** (begin/end pairs at same indentation)
+- **Control flow alignment** showing decision structure clearly
+- **Scope reflection** through indentation hierarchy
+- **Declaration organization** with appropriate keyword positioning
+
+### Consistency Application
+Apply indentation rules uniformly across all AL objects, maintain consistent patterns within teams, and use automated formatting tools where possible to ensure compliance.
+
+### Readability Enhancement
+Structure keyword indentation to support quick visual parsing of code organization. Consistent indentation reduces cognitive load when reviewing complex AL procedures.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Inconsistent indentation increments** creating visual confusion
+- **Misaligned begin/end pairs** obscuring block boundaries
+- **Random keyword positioning** without logical organization
+- **Mixed indentation styles** within single AL object
+- **Excessive indentation** making code difficult to follow
+
+Poor keyword indentation makes code structure unclear and increases the difficulty of understanding control flow and scope relationships.
+
+*Implementation examples: see samples/al-keyword-indentation-rules.md*
+*Related patterns: al-line-start-keyword-positioning.md, al-case-action-formatting.md*

package/embedded-knowledge/domains/roger-reviewer/al-line-start-keyword-positioning.md

@@ -0,0 +1,76 @@
+---
+title: "AL Line Start Keyword Positioning"
+domain: "roger-reviewer"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["keywords", "line-positioning", "code-structure"]
+samples: "samples/al-line-start-keyword-positioning.md"
+type: "improvement-pattern"
+category: "code-formatting"
+pattern_type: "good"
+severity: "medium"
+impact_level: "medium"
+improvement_suggestion: "Position AL keywords at line start with consistent alignment to show code structure"
+implementation_steps: ["identify-keyword-patterns", "apply-positioning-rules", "validate-alignment"]
+validation_criteria: ["consistent-keyword-positioning", "clear-structure-indication"]
+technical_areas: ["al-code"]
+---
+
+# AL Line Start Keyword Positioning
+
+## Overview
+
+Strategic positioning of AL keywords at line starts creates clear visual anchors that help developers quickly identify code structure, control flow patterns, and logical organization. Consistent keyword positioning improves code scanability and reduces cognitive load during code review.
+
+**Key Principle**: Position keywords at line starts with consistent alignment to create clear visual structure markers.
+
+## Strategic Framework
+
+### Visual Structure Creation
+- **Keyword Anchoring**: Keywords as visual reference points for code organization
+- **Scan Optimization**: Positioning that supports quick visual code parsing
+- **Structure Indication**: Keyword placement that reveals code hierarchy
+- **Consistency Standards**: Uniform positioning patterns across codebase
+
+### Readability Enhancement
+Line start keyword positioning helps developers quickly identify major code sections, control flow changes, and logical boundaries within AL procedures and functions.
+
+## Architecture Focus
+
+### Positioning Patterns
+- **Control Flow Keywords**: if, else, while positioned as structure markers
+- **Block Delimiters**: begin, end placement showing scope boundaries
+- **Declaration Keywords**: var, procedure positioning for clear identification
+- **Statement Keywords**: Consistent placement for readability optimization
+
+### Alignment Strategies
+Establish consistent rules for keyword alignment that work well with AL language structure and support effective code organization patterns.
+
+## Best Practices
+
+### Keyword Placement Rules
+- **Line start positioning** for major structural keywords
+- **Consistent alignment** within code blocks and sections
+- **Clear separation** from surrounding code elements
+- **Logical grouping** of related keyword structures
+- **Visual hierarchy** through strategic keyword positioning
+
+### Structure Clarity
+Use keyword positioning to create clear visual markers for code organization. Position keywords to support quick identification of major code sections and control flow patterns.
+
+### Consistency Application
+Apply keyword positioning rules consistently across all AL objects. Establish team standards for keyword placement that enhance code readability and maintainability.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Inconsistent keyword alignment** creating visual confusion
+- **Mid-line keyword placement** reducing structure visibility
+- **Random positioning** without logical organization principles
+- **Poor separation** from surrounding code elements
+- **Mixed positioning styles** within single AL object
+
+Inconsistent keyword positioning makes code structure harder to parse and reduces the effectiveness of visual code organization techniques.
+
+*Implementation examples: see samples/al-line-start-keyword-positioning.md*
+*Related patterns: al-keyword-indentation-rules.md, al-statement-per-line-rule.md*

package/embedded-knowledge/domains/roger-reviewer/al-separate-if-else-formatting.md

@@ -0,0 +1,76 @@
+---
+title: "AL Separate If Else Formatting"
+domain: "roger-reviewer"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["if-statements", "conditional-logic", "formatting"]
+samples: "samples/al-separate-if-else-formatting.md"
+type: "improvement-pattern"
+category: "code-formatting"
+pattern_type: "good"
+severity: "medium"
+impact_level: "medium"
+improvement_suggestion: "Format if-else statements with clear separation to show conditional logic structure"
+implementation_steps: ["separate-conditional-blocks", "align-if-else-keywords", "validate-readability"]
+validation_criteria: ["clear-conditional-separation", "consistent-alignment"]
+technical_areas: ["al-code"]
+---
+
+# AL Separate If Else Formatting
+
+## Overview
+
+Proper formatting of if-else statements in AL code with clear separation between conditional branches improves readability and helps developers understand decision logic structure. Separate formatting makes complex conditional logic easier to follow and maintain.
+
+**Key Principle**: Format if-else statements with clear visual separation between conditional branches to highlight decision structure.
+
+## Strategic Framework
+
+### Conditional Logic Clarity
+- **Branch Separation**: Clear visual distinction between if and else branches
+- **Decision Structure**: Formatting that reveals conditional logic organization
+- **Readability Focus**: Layout that supports quick comprehension of decision flow
+- **Consistency Standards**: Uniform if-else formatting across codebase
+
+### Control Flow Visualization
+If-else formatting should make decision paths immediately apparent to code reviewers. Clear separation helps developers understand alternative execution paths and their relationships.
+
+## Architecture Focus
+
+### Formatting Patterns
+- **Keyword Alignment**: Consistent positioning of if and else keywords
+- **Branch Separation**: Visual spacing between conditional branches
+- **Block Structure**: Clear indication of conditional block boundaries
+- **Nested Conditionals**: Proper formatting for complex decision trees
+
+### Visual Organization
+Structure if-else statements to support quick visual parsing of conditional logic. Use consistent formatting patterns that work well with AL language syntax.
+
+## Best Practices
+
+### Separation Techniques
+- **Clear keyword positioning** for if and else statements
+- **Appropriate spacing** between conditional branches
+- **Consistent indentation** within conditional blocks
+- **Visual boundaries** around conditional logic sections
+- **Aligned block structures** for easy scanning
+
+### Readability Optimization
+Format if-else statements to minimize cognitive load when understanding conditional logic. Use whitespace and alignment effectively to create clear decision structure.
+
+### Complex Conditionals
+For nested or complex if-else structures, use additional spacing and indentation to maintain clarity. Consider refactoring overly complex conditional logic into separate methods.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Cramped if-else formatting** without adequate separation
+- **Inconsistent keyword alignment** obscuring structure
+- **Poor indentation** in conditional blocks
+- **Unclear branch boundaries** making logic hard to follow
+- **Overly complex nested conditionals** without proper formatting
+
+Poor if-else formatting makes conditional logic harder to understand and increases the likelihood of errors during code maintenance.
+
+*Implementation examples: see samples/al-separate-if-else-formatting.md*
+*Related patterns: al-end-else-pairing.md, al-keyword-indentation-rules.md*

package/embedded-knowledge/domains/roger-reviewer/al-standard-abbreviations.md

@@ -0,0 +1,96 @@
+---
+title: "AL Standard Abbreviations"
+domain: "roger-reviewer"
+difficulty: "beginner"
+bc_versions: "14+"
+tags: ["abbreviations", "naming", "standards", "reference"]
+type: "improvement-pattern"
+category: "code-quality"
+pattern_type: "good"
+severity: "high"
+impact_level: "high"
+improvement_suggestion: "Use only Microsoft-approved abbreviations to maintain consistency with Business Central platform"
+implementation_steps: ["verify-platform-abbreviations", "apply-standard-patterns", "validate-consistency"]
+validation_criteria: ["platform-compliant-abbreviations", "consistent-usage"]
+technical_areas: ["al-code"]
+---
+
+# AL Standard Abbreviations
+
+## Overview
+
+Business Central uses standardized abbreviations throughout the platform for consistency and space efficiency. These abbreviations are deeply embedded in field names, variable naming, and API structures across all BC modules.
+
+**Key Principle**: Use only established BC abbreviations to maintain platform consistency and avoid confusion with standard BC objects and APIs.
+
+## Strategic Framework
+
+### Core Business Abbreviations
+- **No.** → Number (CustomerNo, ItemNo, DocumentNo)
+- **Qty** → Quantity (BaseQty, OutstandingQty, ReservedQty)
+- **Amt** → Amount (SalesAmt, CostAmt, DiscountAmt)
+- **Desc** → Description (ItemDesc, CustomerDesc)
+- **LCY** → Local Currency (AmountLCY, UnitCostLCY)
+- **FCY** → Foreign Currency (AmountFCY, UnitPriceFCY)
+
+### Financial and Accounting
+- **G/L** → General Ledger (GLEntry, GLAccount)
+- **VAT** → Value Added Tax (VATEntry, VATAmount)
+- **A/R** → Accounts Receivable (ARAmount)
+- **A/P** → Accounts Payable (APAmount)
+- **WIP** → Work in Progress (WIPEntry)
+- **COGS** → Cost of Goods Sold (COGSAmount)
+
+### Operations and Inventory
+- **UOM** → Unit of Measure (BaseUOM, SalesUOM)
+- **BOM** → Bill of Materials (BOMComponent)
+- **SKU** → Stock Keeping Unit (SKUCode)
+- **Whse** → Warehouse (WhseEntry, WhseShipment)
+- **Invt** → Inventory (InvtPostingGroup)
+- **Prod** → Production (ProdOrder, ProdBOMLine)
+
+## Architecture Focus
+
+### Platform Integration
+BC abbreviations ensure seamless integration with standard platform objects, APIs, and external systems expecting specific field naming patterns.
+
+### Database Considerations
+Abbreviations help manage field name length limits while maintaining readability. Critical for table and field names that interface with external systems.
+
+### API Consistency
+Standard abbreviations ensure API field names match platform conventions, maintaining compatibility with Microsoft and third-party integrations.
+
+### Localization Support
+Platform abbreviations support localization frameworks where translations may require different text lengths while maintaining field name consistency.
+
+## Best Practices
+
+### Approved Usage Only
+- **Platform Standards**: Use only abbreviations established in BC base application
+- **Consistency Check**: Verify abbreviations match existing BC field names
+- **Avoid Custom**: Never create new abbreviations without platform precedent
+- **Documentation**: When platform lacks precedent, document rationale and team approval
+
+### Context-Appropriate Application
+- **Field Names**: Essential for table field naming within character limits
+- **Variable Names**: Use when matching related field names or platform objects
+- **Procedure Names**: Generally avoid abbreviations in procedure names
+- **Comments**: Spell out full terms in documentation and comments
+
+### Validation Requirements
+- **Platform Verification**: Cross-check against BC object definitions
+- **API Compatibility**: Ensure abbreviations don't conflict with standard APIs
+- **Extension Guidelines**: Follow AppSource and per-tenant extension naming requirements
+- **Team Standards**: Maintain approved abbreviation list for project-specific terms
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Custom Creations**: Never invent abbreviations not used in BC platform
+- **Inconsistent Forms**: Don't mix "Descr" and "Desc" for same concept
+- **Ambiguous Terms**: Avoid abbreviations with multiple possible meanings
+- **Platform Conflicts**: Don't use abbreviations that conflict with BC standards
+
+Invalid abbreviations cause integration failures and platform inconsistencies, potentially leading to AppSource validation failures.
+
+*Related patterns: al-variable-naming-conventions.md, al-field-naming.md*

package/embedded-knowledge/domains/roger-reviewer/al-statement-per-line-rule.md

@@ -0,0 +1,76 @@
+---
+title: "AL Statement Per Line Rule"
+domain: "roger-reviewer"
+difficulty: "beginner"
+bc_versions: "14+"
+tags: ["statements", "line-organization", "readability"]
+samples: "samples/al-statement-per-line-rule.md"
+type: "improvement-pattern"
+category: "code-formatting"
+pattern_type: "good"
+severity: "medium"
+impact_level: "medium"
+improvement_suggestion: "Write one AL statement per line to improve readability and debugging capability"
+implementation_steps: ["separate-multiple-statements", "format-single-statements", "validate-clarity"]
+validation_criteria: ["one-statement-per-line", "improved-readability"]
+technical_areas: ["al-code"]
+---
+
+# AL Statement Per Line Rule
+
+## Overview
+
+Writing one AL statement per line improves code readability, simplifies debugging, and makes code maintenance more effective. The one-statement-per-line rule is a fundamental formatting practice that enhances code clarity and supports better development workflows.
+
+**Key Principle**: Each line should contain exactly one complete AL statement to maximize readability and debugging effectiveness.
+
+## Strategic Framework
+
+### Readability Enhancement
+- **Visual Clarity**: Each statement clearly separated and identifiable
+- **Scanning Efficiency**: Easy visual parsing of code logic
+- **Debugging Support**: Line-by-line debugging capability
+- **Code Review**: Simplified review process with clear statement boundaries
+
+### Maintenance Benefits
+Single statements per line make code changes easier to track, debug, and understand. This pattern supports effective version control and collaborative development practices.
+
+## Architecture Focus
+
+### Statement Organization
+- **Clear Boundaries**: Each statement on separate line with proper termination
+- **Logical Flow**: Sequential statement arrangement for easy following
+- **Visual Structure**: Line organization that reflects code logic
+- **Error Isolation**: Individual statements for easier error identification
+
+### Development Workflow
+One-statement-per-line formatting integrates well with debugging tools, version control systems, and code review processes commonly used in AL development.
+
+## Best Practices
+
+### Statement Formatting
+- **Single statement per line** with proper semicolon termination
+- **Appropriate indentation** for each statement level
+- **Clear statement separation** without cramming multiple operations
+- **Logical ordering** of related statements
+- **Consistent formatting** across all AL objects
+
+### Code Organization
+Organize statements in logical sequence, group related operations appropriately, and use consistent formatting patterns that support easy code comprehension.
+
+### Debugging Support
+Structure code to support effective debugging by ensuring each line represents a single operation that can be stepped through individually.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Multiple statements per line** reducing readability
+- **Cramped code formatting** without proper separation
+- **Complex compound statements** difficult to debug
+- **Inconsistent line organization** across AL objects
+- **Poor statement grouping** without logical organization
+
+Multiple statements per line make code harder to read, debug, and maintain. This pattern increases cognitive load and reduces development efficiency.
+
+*Implementation examples: see samples/al-statement-per-line-rule.md*
+*Related patterns: al-readability-optimization.md, al-blank-line-organization.md*