Architecture Decisions

Accepted

We need a flexible and extensible way to implement different linting rules for AsciiDoc documents.

We will use an abstract base class Rule with a defined interface that all concrete rules must implement.

Positive
- Consistent interface for all rules
- Easy to add new rules
- Clear separation of concerns
- Simplified testing through common interface
Negative
- Additional abstraction layer
- Slight performance overhead

Accepted

Rule violations need to be reported in a consistent and informative way.

We will use a Finding data class with fields for message, severity, position, rule ID, and context.

Positive
- Structured error reporting
- Rich context for violations
- Consistent error format
Negative
- More complex than simple string messages
- Requires more memory for storing findings

Accepted

Rules need to process AsciiDoc content and identify violations efficiently.

Each rule will process the content line by line, using regular expressions for pattern matching.

Positive
- Simple implementation
- Good performance for most cases
- Easy to understand and maintain
Negative
- Limited context awareness
- May miss some complex patterns
- Regular expressions can become complex

Accepted

Rules need to be thoroughly tested to ensure reliable operation.

Each rule will have its own test class with multiple test methods covering various scenarios.

Positive
- High test coverage
- Clear test organization
- Easy to add new test cases
Negative
- More maintenance effort
- Longer test execution time

Feedback

Was this page helpful?

Sorry to hear that. Please tell us how we can improve.