Pattern Detection

Pattern Recognition

When to Use

• Before writing new code to ensure consistency with existing patterns
• During code review to verify alignment with established conventions
• When onboarding to understand project-specific practices
• Before refactoring to preserve intentional design decisions

Core Methodology

Pattern Discovery Process

1. Survey representative files: Read 3-5 files of the type you will create or modify
2. Identify recurring structures: Note repeated patterns in naming, organization, imports
3. Verify intentionality: Check if patterns are documented or consistently applied
4. Apply discovered patterns: Use the same conventions in new code

Priority Order for Pattern Sources

1. Existing code in the same module/feature - Most authoritative
2. Project style guides or CONTRIBUTING.md - Explicit documentation
3. Test files - Often reveal expected patterns and naming
4. Similar files in adjacent modules - Fallback when no direct examples exist

Naming Convention Recognition

File Naming Patterns

Detect and follow the project's file naming style:

Function/Method Naming

Identify the project's verb conventions:

• get vs fetch vs retrieve for data access
• create vs add vs new for creation
• update vs set vs modify for mutations
• delete vs remove vs destroy for deletion
• is/has/can/should prefixes for booleans

Variable Naming

Detect pluralization and specificity patterns:

• Singular vs plural for collections (user vs users vs userList)
• Hungarian notation presence (strName, iCount)
• Private member indicators (_private, #private, mPrivate)

Architectural Pattern Recognition

Layer Identification

Recognize how the codebase separates concerns:

COMMON LAYERING PATTERNS:
- MVC: controllers/, models/, views/
- Clean Architecture: domain/, application/, infrastructure/
- Hexagonal: core/, adapters/, ports/
- Feature-based: features/auth/, features/billing/
- Type-based: components/, services/, utils/

Dependency Direction

Identify import patterns that reveal architecture:

• Which modules import from which (dependency flow)
• Shared vs feature-specific code boundaries
• Framework code vs application code separation

State Management Patterns

Recognize how state flows through the application:

• Global stores (Redux, Vuex, MobX patterns)
• React Context usage patterns
• Service layer patterns for backend state
• Event-driven vs request-response patterns

Testing Pattern Recognition

Test Organization

Identify how tests are structured:

Test Naming Conventions

Detect the project's test description style:

• BDD style: it('should return user when found')
• Descriptive: test('getUser returns user when id exists')
• Function-focused: test_get_user_returns_user_when_found

Test Structure Patterns

Recognize Arrange-Act-Assert or Given-When-Then patterns:

• Setup block conventions (beforeEach, fixtures, factories)
• Assertion style (expect vs assert vs should)
• Mock/stub patterns (jest.mock vs sinon vs manual)

Code Organization Patterns

Import Organization

Identify import ordering and grouping:

COMMON IMPORT PATTERNS:
1. External packages first, internal modules second
2. Grouped by type (React, libraries, local)
3. Alphabetized within groups
4. Absolute imports vs relative imports preference

Export Patterns

Recognize module boundary conventions:

• Default exports vs named exports preference
• Barrel files (index.ts re-exports) presence
• Public API definition patterns

Comment and Documentation Patterns

Identify documentation conventions:

• JSDoc/TSDoc presence and style
• Inline comment frequency and style
• README conventions per module/feature

Best Practices

• Follow existing patterns even if imperfect - Consistency trumps personal preference
• Document deviations explicitly - When breaking patterns intentionally, explain why
• Pattern changes require migration - Dont introduce new patterns without updating existing code
• Check tests for patterns too - Test code often reveals expected conventions
• Prefer explicit over implicit - When patterns are unclear, ask or document assumptions

Anti-Patterns to Avoid

• Mixing naming conventions in the same codebase
• Introducing new architectural patterns without team consensus
• Assuming patterns from other projects apply here
• Ignoring test patterns when writing implementation
• Creating "special" files that dont follow established structure

References

• examples/common-patterns.md - Concrete examples of pattern recognition in action