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

package/embedded-knowledge/domains/roger-reviewer/al-unnecessary-else-elimination.md

@@ -0,0 +1,86 @@
+---
+title: "AL Unnecessary Else Elimination"
+domain: "roger-reviewer"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["control-flow", "code-clarity", "optimization", "refactoring"]
+type: "improvement-pattern"
+category: "code-quality"
+pattern_type: "good"
+severity: "medium"
+impact_level: "medium"
+improvement_suggestion: "Eliminate unnecessary else statements to improve code readability and reduce nesting complexity"
+implementation_steps: ["identify-redundant-else", "apply-early-exit-patterns", "validate-logic-flow"]
+validation_criteria: ["reduced-complexity", "improved-readability"]
+technical_areas: ["al-code"]
+samples: "samples/al-unnecessary-else-elimination.md"
+---
+
+# AL Unnecessary Else Elimination
+
+## Overview
+
+Eliminating unnecessary else statements in AL code improves readability, reduces nesting complexity, and creates cleaner control flow. This optimization technique focuses on early returns and guard clauses to simplify conditional logic.
+
+**Key Principle**: Use early exit patterns and guard clauses to eliminate else statements when the if block ends execution flow.
+
+## Strategic Framework
+
+### Early Return Pattern
+When an if statement ends with exit, return, or error, the subsequent else becomes unnecessary. The code after the if statement naturally handles the alternative case.
+
+### Guard Clause Implementation
+Replace nested if-else structures with guard clauses at the beginning of procedures. This creates a clear validation phase followed by main logic.
+
+### Positive Logic Flow
+Structure conditions to handle the expected path first, with error or edge cases handled through early exits.
+
+### Reduced Cognitive Load
+Fewer else statements mean less mental tracking of conditional paths and reduced nesting complexity.
+
+## Architecture Focus
+
+### Control Flow Simplification
+**Linear Flow**: Early exits create straightforward top-to-bottom execution paths
+**Reduced Nesting**: Elimination of else statements flattens nested conditional structures
+**Clear Validation**: Guard clauses separate input validation from business logic
+**Maintainable Structure**: Simplified control flow reduces modification complexity
+
+### Error Handling Integration
+Guard clauses naturally integrate with AL error handling patterns, creating clear separation between validation failures and business logic execution.
+
+### Performance Considerations
+Early exits can improve performance by avoiding unnecessary condition evaluation and code execution in error scenarios.
+
+## Best Practices
+
+### Identification Patterns
+- **Exit After If**: When if block contains exit statement, else is unnecessary
+- **Error After If**: When if block throws error, else clause is redundant
+- **Return After If**: When if block returns value, subsequent code handles alternative
+- **Guard Conditions**: Replace if-else with early validation checks
+
+### Refactoring Approach
+1. **Identify Candidates**: Look for if statements ending with exit/error/return
+2. **Verify Logic**: Ensure else block logic can move to main flow
+3. **Apply Transformation**: Remove else, unindent subsequent code
+4. **Test Thoroughly**: Validate that logic behavior remains unchanged
+
+### Readability Enhancement
+- **Clear Intent**: Early exits make error conditions immediately obvious
+- **Reduced Indentation**: Flatter code structure improves visual scanning
+- **Logical Grouping**: Validation separated from main business logic
+- **Simplified Debugging**: Fewer conditional paths to trace during troubleshooting
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Complex Else Logic**: Don't eliminate else when it contains substantial conditional logic
+- **Parallel Conditions**: Keep else when both paths are equally valid business cases
+- **State Dependencies**: Maintain else when subsequent code depends on if condition state
+- **Performance Impact**: Avoid elimination if it duplicates expensive operations
+
+Eliminating else statements that contain important alternative logic paths creates incorrect program behavior and should be avoided.
+
+*Related patterns: al-early-exit-patterns.md, al-guard-clauses.md*
+*Implementation examples: see samples/al-unnecessary-else-elimination.md*

package/embedded-knowledge/domains/roger-reviewer/al-variable-declaration-order.md

@@ -0,0 +1,90 @@
+---
+title: "AL Variable Declaration Order"
+domain: "roger-reviewer"
+difficulty: "beginner"
+bc_versions: "14+"
+tags: ["variables", "declaration", "code-structure", "organization"]
+type: "improvement-pattern"
+category: "code-quality"
+pattern_type: "good"
+severity: "medium"
+impact_level: "medium"
+improvement_suggestion: "Organize variable declarations in logical order to improve code readability and maintainability"
+implementation_steps: ["establish-declaration-order", "group-related-variables", "apply-consistent-patterns"]
+validation_criteria: ["consistent-declaration-order", "improved-organization"]
+technical_areas: ["al-code"]
+samples: "samples/al-variable-declaration-order.md"
+---
+
+# AL Variable Declaration Order
+
+## Overview
+
+Systematic variable declaration ordering in AL improves code readability, maintenance efficiency, and team collaboration. Consistent ordering patterns help developers quickly locate and understand variable purposes within procedures and objects.
+
+**Key Principle**: Group related variables together and order by importance, scope, and usage patterns to create predictable code structure.
+
+## Strategic Framework
+
+### Standard Declaration Sequence
+1. **Input Parameters**: Method inputs in logical order
+2. **Output Parameters**: Return values and output references
+3. **Record Variables**: Primary business objects
+4. **Temporary Records**: Buffer and temporary storage
+5. **Management Objects**: Codeunits, pages, reports
+6. **Simple Data Types**: Text, Integer, Decimal, Boolean
+7. **System Objects**: Dialog, File, Stream variables
+
+### Grouping Principles
+- **Related Functionality**: Group variables serving similar purposes
+- **Usage Frequency**: Most-used variables declared first within groups
+- **Data Flow**: Input → Processing → Output variable ordering
+- **Alphabetical Within Groups**: When no logical order exists, use alphabetical sorting
+
+## Architecture Focus
+
+### Scope-Based Organization
+**Global Variables** follow object-level importance - core business records first, followed by supporting objects and simple types.
+
+**Local Variables** prioritize procedure-specific logic flow - parameters first, then main processing variables, finally utility variables.
+
+**Temporary Variables** grouped separately to clearly indicate their transient nature and memory management requirements.
+
+### Type-Specific Patterns
+- **Record Variables**: Order by relationship hierarchy (master records before detail records)
+- **Management Variables**: Group by functional area (sales management, posting management)
+- **Configuration Variables**: Place setup and configuration records after main business records
+- **System Variables**: Group system objects (Dialog, File) at end of declarations
+
+## Best Practices
+
+### Logical Grouping
+- **Business Context First**: Primary business objects at top of declarations
+- **Supporting Objects Next**: Helper records and management objects follow
+- **Utility Variables Last**: Counters, flags, and temporary values at end
+- **Related Variables Together**: Keep functionally related variables adjacent
+
+### Readability Enhancement
+- **Blank Line Separation**: Use blank lines between logical groups
+- **Inline Comments**: Document variable groups and their collective purpose
+- **Consistent Spacing**: Align variable names and types for visual clarity
+- **Descriptive Ordering**: Within groups, order by business logic flow
+
+### Maintenance Considerations
+- **Standard Patterns**: Follow consistent ordering across all team code
+- **Refactoring Support**: Logical ordering simplifies variable impact analysis
+- **Documentation**: Variable order should tell the story of the procedure's logic
+- **Review Guidelines**: Include declaration order in code review checklists
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Random Ordering**: Variables declared in order of coding rather than logical importance
+- **Mixed Types**: Simple types scattered between complex objects
+- **No Grouping**: Related variables separated by unrelated declarations
+- **Inconsistent Patterns**: Different ordering approaches within same codebase
+
+Poorly ordered declarations make code changes more error-prone and time-consuming, with variable relationships becoming unclear and increasing maintenance risk.
+
+*Related patterns: al-variable-naming-conventions.md, al-code-organization.md*
+*Implementation examples: see samples/al-variable-declaration-order.md*

package/embedded-knowledge/domains/roger-reviewer/al-variable-naming-conventions.md

@@ -0,0 +1,82 @@
+---
+title: "AL Variable Naming Conventions"
+domain: "roger-reviewer"
+difficulty: "beginner"
+bc_versions: "14+"
+tags: ["variables", "naming", "code-style", "readability"]
+type: "improvement-pattern"
+category: "code-quality"
+pattern_type: "good"
+severity: "medium"
+impact_level: "medium"
+improvement_suggestion: "Apply consistent variable naming conventions to enhance code readability and maintainability"
+implementation_steps: ["establish-naming-standards", "apply-consistent-patterns", "validate-conventions"]
+validation_criteria: ["consistent-naming-application", "improved-readability"]
+technical_areas: ["al-code"]
+---
+
+# AL Variable Naming Conventions
+
+## Overview
+
+Consistent variable naming in AL code improves readability, maintainability, and team collaboration. Business Central development follows Microsoft's naming conventions with specific adaptations for ERP domain concepts.
+
+**Key Principle**: Variable names should clearly communicate purpose, scope, and data type without requiring additional documentation.
+
+## Strategic Framework
+
+### Naming Pattern Hierarchy
+- **Local Variables**: CamelCase starting with lowercase (customerRecord, totalAmount)
+- **Global Variables**: CamelCase starting with uppercase (CustomerBuffer, TotalSalesAmount)
+- **Constants**: ALL_CAPS with underscores (MAX_RETRY_COUNT, DEFAULT_TIMEOUT)
+- **Temporary Variables**: Prefix with "Temp" (TempCustomer, TempItemLedgerEntry)
+
+### Domain-Specific Patterns
+- **Record Variables**: Use table name without "Record" suffix (Customer, not CustomerRecord)
+- **Buffer Variables**: Append "Buffer" for temporary storage (CustomerBuffer)
+- **Counter Variables**: Use descriptive names (CustomerCount, not i or counter)
+- **Boolean Variables**: Use positive phrasing with "Is/Has/Can" prefixes (IsPosted, HasPermission)
+
+## Architecture Focus
+
+### Scope-Based Conventions
+**Local Variables** follow function-specific naming that clearly indicates their role within the procedure context.
+
+**Global Variables** use broader context names that reflect their application-wide purpose and lifetime.
+
+**Parameter Variables** match their usage pattern - input parameters use descriptive names, output parameters often include "Result" or "Output" suffixes.
+
+### Type-Specific Patterns
+- **Codeunit Variables**: Include "Mgt" or "Management" suffix (CustomerMgt, SalesMgt)
+- **Page Variables**: Use "Page" suffix when storing page references (CustomerPage)
+- **Report Variables**: Use "Report" suffix for report references (SalesReport)
+- **XMLport Variables**: Use "XMLport" suffix (CustomerXMLport)
+
+## Best Practices
+
+### Clarity and Context
+- **Avoid Abbreviations**: Use complete words unless standard BC abbreviations (Qty, Amt, No.)
+- **Include Units**: For measurements, include unit context (AmountLCY, QtyBase)
+- **Specify Direction**: For parameters, indicate flow (CustomerNoIn, ResultOut)
+- **Use Business Terms**: Prefer domain language over technical terms (PostingDate vs DateVar)
+
+### Consistency Patterns
+- **Maintain Team Standards**: Follow established project conventions over personal preferences
+- **Use Standard Prefixes**: Apply consistent prefixes for similar variable types
+- **Document Deviations**: When breaking convention for specific reasons, include inline comments
+- **Review and Refactor**: Regular code reviews should enforce naming consistency
+
+### Hungarian Notation Avoidance
+Modern AL development avoids Hungarian notation. Variable types are clear from declaration context, making type prefixes unnecessary and potentially misleading during refactoring.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Generic Names**: Avoid "Rec", "TempRec", "Buffer" without context
+- **Misleading Abbreviations**: Don't create custom abbreviations (CustAddr vs CustomerAddress)
+- **Type Prefixes**: Avoid Hungarian notation (strName, intCount, bolIsValid)
+- **Inconsistent Casing**: Mixed casing patterns within same codebase
+
+Poor variable naming creates maintenance problems and makes code harder to understand, review, and modify effectively.
+
+*Related patterns: al-variable-declaration-order.md, al-standard-abbreviations.md*

package/embedded-knowledge/domains/roger-reviewer/begin-block-statement-clarity.md

@@ -0,0 +1,78 @@
+---
+title: "Begin Block Statement Clarity for Developer Experience"
+domain: "roger-reviewer"
+difficulty: "beginner"
+bc_versions: "14+"
+tags: ["user-experience", "code-clarity", "begin-blocks", "developer-productivity", "code-comprehension"]
+prerequisites: ["al-syntax", "code-style"]
+---
+# Begin Block Statement Clarity for Developer Experience
+
+## Overview
+
+Strategic use of begin-end blocks enhances developer experience by creating clear code structure boundaries, improving comprehension speed, and reducing cognitive load when navigating complex procedural logic.
+
+**Clarity Principle**: Use begin-end blocks consistently to create visual and logical boundaries that help developers quickly understand code structure and flow.
+
+## Strategic Framework
+
+### Developer Comprehension Strategy
+- **Visual boundaries**: Use begin-end blocks to clearly delineate code sections
+- **Logical grouping**: Group related statements within clear block structures
+- **Navigation efficiency**: Create landmarks that help developers orient within procedures
+- **Maintenance clarity**: Make code modifications easier by clarifying block scope
+
+### Cognitive Load Reduction
+- **Structural indicators**: Provide visual cues for code organization
+- **Scope clarity**: Make variable and statement scope immediately apparent
+- **Flow comprehension**: Help developers follow execution paths quickly
+- **Error prevention**: Reduce mistakes caused by unclear code boundaries
+
+## Architecture Patterns
+
+### Explicit Block Structure
+Use begin-end blocks even when not syntactically required to create consistent visual patterns that improve code readability and maintainability.
+
+### Logical Section Grouping
+Organize related statements within begin-end blocks to create clear functional sections within larger procedures.
+
+### Nested Block Clarity
+Structure nested blocks with consistent indentation and clear boundary markers to maintain comprehension in complex logic structures.
+
+## Implementation Guidelines
+
+### Block Usage Standards
+- **Consistent application**: Use begin-end blocks uniformly across similar code structures
+- **Logical boundaries**: Align block boundaries with functional or logical code sections
+- **Indentation consistency**: Maintain clear visual hierarchy through consistent indentation
+- **Comment integration**: Use comments with blocks to explain section purpose
+
+### Developer Experience Optimization
+Format blocks to support quick visual scanning, easy modification, and clear understanding of code structure and purpose.
+
+### Team Collaboration Enhancement
+Use consistent block patterns that help team members quickly understand and modify each other's code.
+
+## Best Practices
+
+### Structural Consistency
+- **Pattern adherence**: Apply consistent begin-end block patterns across the codebase
+- **Visual hierarchy**: Use indentation to show clear nesting and relationship patterns
+- **Purposeful grouping**: Organize statements within blocks based on logical relationships
+- **Maintenance support**: Structure blocks to facilitate easy code modification and extension
+
+### Readability Enhancement
+Design block usage to minimize the time required for developers to understand code structure and locate specific functionality.
+
+### Tool Integration
+Configure development tools to support consistent block formatting and provide visual indicators for block boundaries.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Inconsistent block usage**: Mixing different approaches to block structure within the same codebase
+- **Unclear boundaries**: Poor indentation or formatting that obscures block structure
+- **Unnecessary complexity**: Over-nesting or excessive block subdivision
+- **Missing logical grouping**: Failing to group related statements within clear block boundaries
+- **Ignored formatting standards**: Manual formatting that creates inconsistent visual patterns
+

package/embedded-knowledge/domains/roger-reviewer/begin-end-positioning-patterns.md

@@ -0,0 +1,76 @@
+---
+title: "Begin/End Positioning in AL Code"
+domain: "roger-reviewer"
+difficulty: "beginner"
+bc_versions: "14+"
+tags: ["code-style", "readability", "structure", "begin-end", "formatting"]
+samples: "samples/begin-end-positioning.md"
+type: "best-practice"
+category: "code-structure"
+pattern_type: "good"
+severity: "low"
+impact_level: "medium"
+improvement_suggestion: "Use consistent begin/end positioning for improved code readability"
+implementation_steps: ["establish-team-standards", "configure-formatting-tools", "apply-consistently"]
+validation_criteria: ["consistent-positioning", "improved-readability", "team-adoption"]
+technical_areas: ["al-code", "formatting"]
+---
+
+# Begin/End Positioning in AL Code
+
+## Overview
+
+Begin/end positioning in AL code significantly impacts readability and maintainability. Strategic placement of begin/end keywords creates visual structure that helps developers quickly understand code flow and hierarchy. The positioning choice affects scan-ability, debugging efficiency, and team collaboration effectiveness.
+
+**Key Principle**: Position begin/end keywords to maximize code readability and create clear visual structure that supports rapid code comprehension.
+
+The "begin as afterword" pattern places the begin keyword on the same line as the procedure declaration, optimizing vertical space while maintaining clear block boundaries. This approach balances conciseness with structural clarity.
+
+## Strategic Framework
+
+### Readability Optimization Patterns
+**Primary Goal**: Create code structure that supports rapid visual scanning and comprehension. Begin/end positioning should enhance, not hinder, a developer's ability to understand code intent and flow.
+
+**Visual Hierarchy**: Consistent begin/end positioning creates predictable visual patterns that help developers navigate code efficiently. The eye learns to recognize structural boundaries, reducing cognitive load during code review and debugging.
+
+### Team Collaboration Benefits
+**Consistency Standards**: Uniform begin/end positioning across team codebases reduces context switching overhead when developers work on different modules. Consistent formatting patterns become familiar navigation aids.
+
+**Code Review Efficiency**: Well-positioned begin/end keywords facilitate faster code reviews by creating clear visual boundaries around logical code blocks. Reviewers can quickly identify scope and structure without mental parsing overhead.
+
+## Architecture Focus
+
+### Structural Clarity Principles
+**Block Boundary Definition**: Begin/end positioning should clearly delineate logical code blocks without creating visual noise. The positioning choice affects how developers perceive code organization and flow.
+
+**Nesting Visualization**: Proper begin/end positioning helps visualize nested code structures, making complex procedure hierarchies easier to understand and maintain.
+
+### Scanning Optimization
+**Vertical Space Efficiency**: Strategic begin/end positioning optimizes vertical screen real estate while maintaining structural clarity. This balance is crucial for modern development environments with limited vertical display space.
+
+**Pattern Recognition**: Consistent positioning patterns enable rapid visual pattern recognition, allowing developers to quickly identify procedure boundaries, conditional blocks, and loop structures.
+
+## Best Practices
+
+### Consistency Implementation
+- **Team Standards**: Establish and document team-wide begin/end positioning standards. Consistency across the codebase is more valuable than individual preference optimization.
+- **Tool Integration**: Configure AL development tools to automatically format begin/end positioning according to team standards. Automated formatting reduces inconsistency and discussion overhead.
+
+### Readability Enhancement
+- **Logical Grouping**: Use begin/end positioning to reinforce logical code grouping. The visual structure should align with the logical structure of the procedure or function.
+- **Debugging Support**: Position begin/end keywords to facilitate debugging workflows. Clear block boundaries help when setting breakpoints and stepping through code execution.
+
+### Professional Standards
+- **Industry Conventions**: Align begin/end positioning with broader AL and Business Central community conventions. This facilitates knowledge transfer and reduces onboarding friction for new team members.
+- **Documentation Integration**: Ensure begin/end positioning supports code documentation patterns. Clear structural boundaries enhance documentation readability and usefulness.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Mixed Positioning**: Avoid mixing different begin/end positioning styles within the same codebase. Inconsistency creates cognitive overhead and reduces code professionalism.
+- **Context-Dependent Formatting**: Don't vary begin/end positioning based on procedure complexity or developer preference. Consistency trumps optimization for specific scenarios.
+- **Excessive Compaction**: Avoid positioning choices that sacrifice readability for minimal space savings. Code clarity should take precedence over character count optimization.
+- **Unclear Boundaries**: Don't use begin/end positioning that obscures logical code block boundaries. The positioning should enhance, not hinder, structural understanding.
+
+*Implementation examples: see samples/begin-end-positioning.md*
+*Related patterns: code-formatting-standards.md, procedure-organization-patterns.md*

package/embedded-knowledge/domains/roger-reviewer/binary-operator-line-positioning.md

@@ -0,0 +1,78 @@
+---
+title: "Binary Operator Line Positioning and Code Readability"
+domain: "roger-reviewer"
+difficulty: "beginner"
+bc_versions: "14+"
+tags: ["code-style", "operators", "readability", "formatting", "line-breaks"]
+prerequisites: ["al-syntax", "code-formatting"]
+---
+# Binary Operator Line Positioning and Code Readability
+
+## Overview
+
+Strategic positioning of binary operators in multi-line expressions enhances code readability by creating clear visual alignment and logical flow, making complex expressions easier to parse and maintain.
+
+**Readability Principle**: Position binary operators consistently to create visual patterns that guide the reader's eye through complex logical and mathematical expressions.
+
+## Strategic Framework
+
+### Visual Alignment Strategy
+- **Leading operators**: Place operators at the beginning of continuation lines
+- **Consistent indentation**: Align continuation lines for visual clarity
+- **Logical grouping**: Use operator positioning to show expression hierarchy
+- **Scanning optimization**: Format for efficient visual parsing of complex conditions
+
+### Expression Flow Design
+- **Left-to-right reading**: Support natural reading patterns in operator placement
+- **Precedence clarity**: Use positioning to reinforce operator precedence
+- **Continuation indicators**: Make line breaks and continuations obvious
+- **Nested expression handling**: Maintain clarity in complex nested conditions
+
+## Architecture Patterns
+
+### Leading Operator Pattern
+Place binary operators at the beginning of continuation lines to create clear visual indicators of expression continuation and logical flow.
+
+### Aligned Continuation Pattern
+Indent continuation lines consistently to create visual columns that make it easy to follow complex multi-line expressions.
+
+### Hierarchical Expression Layout
+Use operator positioning and indentation to visually represent the logical structure of complex boolean and mathematical expressions.
+
+## Implementation Guidelines
+
+### Formatting Standards
+- **Operator placement**: Consistently place binary operators at line beginnings
+- **Indentation depth**: Use consistent indentation for continuation lines
+- **Spacing consistency**: Maintain uniform spacing around operators
+- **Line break logic**: Break lines at logical expression boundaries
+
+### Complex Expression Handling
+Break long expressions at appropriate logical points, using operator positioning to maintain readability and show the relationship between expression parts.
+
+### Tool Integration
+Configure code formatting tools to apply consistent binary operator positioning rules across the codebase automatically.
+
+## Best Practices
+
+### Consistency Standards
+- **Team conventions**: Establish and follow team-wide operator positioning standards
+- **Automated formatting**: Use formatting tools to maintain consistency
+- **Code review focus**: Include operator positioning in code review criteria
+- **Style guide documentation**: Document operator positioning rules clearly
+
+### Readability Optimization
+Format expressions to minimize cognitive load, using operator positioning and alignment to create visual patterns that aid comprehension.
+
+### Maintenance Considerations
+Choose operator positioning patterns that remain clear and maintainable as expressions grow in complexity over time.
+
+## Anti-Patterns
+
+### Avoid These Approaches
+- **Inconsistent positioning**: Mixing operator placement styles within the same codebase
+- **Poor alignment**: Misaligned continuation lines that create visual confusion
+- **Trailing operators**: Placing operators at the end of lines where they're less visible
+- **Random line breaks**: Breaking lines without considering logical expression structure
+- **Ignored formatting tools**: Manual formatting instead of automated consistency
+

package/embedded-knowledge/domains/roger-reviewer/boolean-expression-simplification-al.md

@@ -0,0 +1,100 @@
+---
+title: "Boolean Expression Simplification in AL"
+domain: "roger-reviewer"
+difficulty: "intermediate"
+bc_versions: "14+"
+tags: ["boolean-expressions", "code-simplification", "readability", "performance", "refactoring"]
+prerequisites: ["al-syntax-basics", "conditional-logic"]
+samples: "samples/boolean-simplification-examples.md"
+---
+
+# Boolean Expression Simplification in AL
+
+## Overview
+
+Complex boolean expressions in AL code often become difficult to read, maintain, and debug. Systematic simplification techniques improve code clarity while maintaining logical correctness and often enhancing performance.
+
+**Core Principle**: Simplify boolean expressions to their most readable form while preserving exact logical behavior.
+
+## Simplification Principles
+
+### De Morgan's Laws Application
+Transform complex negations using logical equivalencies:
+- **NOT (A AND B) = (NOT A) OR (NOT B)**
+- **NOT (A OR B) = (NOT A) AND (NOT B)**
+
+These transformations often reveal simpler positive conditions that improve readability.
+
+### Short-Circuit Evaluation Optimization
+AL evaluates boolean expressions left-to-right with short-circuiting:
+- **AND expressions**: Place most likely false conditions first
+- **OR expressions**: Place most likely true conditions first
+- **Performance impact**: Expensive operations should appear later in expression
+
+### Positive Logic Preference
+Express conditions in positive terms when possible:
+- **Avoid double negatives**: Replace `not (not Condition)` with `Condition`
+- **Prefer positive checks**: Use `IsValid` instead of `not IsInvalid`
+- **Clear intent**: Positive expressions communicate intent more directly
+
+## Common Simplification Patterns
+
+### Redundant Condition Elimination
+```
+// Complex: Redundant conditions
+if (Status = Status::Active) and (Status <> Status::Inactive) then
+```
+**Simplification**: Remove redundant negative condition - if Status is Active, it cannot be Inactive.
+
+### Range Condition Optimization
+```
+// Complex: Multiple range checks
+if (Amount >= 0) and (Amount <= MaxAmount) and (Amount <> 0) then
+```
+**Simplification**: Combine overlapping conditions and eliminate redundancy.
+
+### Nested Condition Flattening
+```
+// Complex: Deep nesting
+if Condition1 then
+    if Condition2 then
+        if Condition3 then
+            ProcessRecord();
+```
+**Simplification**: Use combined boolean expression with early exit patterns.
+
+## Refactoring Techniques
+
+### Extract Boolean Variables
+Replace complex inline expressions with descriptive boolean variables:
+- **Improved readability**: Self-documenting variable names explain logic
+- **Easier debugging**: Individual conditions can be evaluated separately
+- **Maintainability**: Changes to logic isolated to variable assignment
+
+### Method Extraction for Complex Logic
+Move complex boolean expressions into dedicated functions:
+- **Single responsibility**: Each function handles one logical concept
+- **Reusability**: Complex conditions can be reused across objects
+- **Testability**: Isolated boolean logic easier to unit test
+
+### Conditional Inversion
+Sometimes inverting conditional logic simplifies overall expression:
+- **Guard clauses**: Use early returns to eliminate nesting
+- **Exception handling**: Check for invalid conditions first
+- **Default behavior**: Structure logic around normal case flow
+
+## Performance Guidelines
+
+Order expressions strategically with expensive operations last, leverage short-circuit evaluation, and always check for null/empty conditions first.
+
+## Readability Guidelines
+
+Use meaningful variable names, logical grouping with parentheses, and consistent team formatting standards for boolean expressions.
+
+## Best Practices
+
+Use truth table analysis for complex expressions, recognize common AL patterns, and ensure behavioral testing preserves original logic during simplification.
+
+*Complete simplification examples: samples/boolean-simplification-examples.md*
+*AL performance patterns: roger-reviewer-index.json#performance-optimization*
+*Refactoring techniques: code-design-index.json#refactoring-patterns*