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

• Survey representative files: Read 3-5 files of the type you will create or modify

• Identify recurring structures: Note repeated patterns in naming, organization, imports

• Verify intentionality: Check if patterns are documented or consistently applied

• Apply discovered patterns: Use the same conventions in new code

Priority Order for Pattern Sources

• Existing code in the same module/feature - Most authoritative

• Project style guides or CONTRIBUTING.md - Explicit documentation

• Test files - Often reveal expected patterns and naming

• 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:

Pattern Example Common In

kebab-case user-profile.ts

Node.js, Vue, Angular

PascalCase UserProfile.tsx

React components

snake_case user_profile.py

Python

camelCase userProfile.js

Legacy JS, Java

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:

Pattern Structure Example

Co-located src/user.ts , src/user.test.ts

Common in modern JS/TS

Mirror tree src/user.ts , tests/src/user.test.ts

Traditional, Java-style

Feature-based src/user/ , src/user/tests/

React, organized features

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