Tech Due Diligence CQ-7: Coding Standards and Consistency
What This Control Requires
The assessor evaluates the consistency of coding practices across the codebase, including adherence to style guides, naming conventions, architectural patterns, and the use of automated tools to enforce coding standards.
In Plain Language
A consistent codebase is one of the clearest signals that a team works well together. When patterns, naming conventions, file organisation, error handling, and architecture follow a coherent style, the code is easier to read, cheaper to maintain, and far less likely to harbour subtle bugs.
Inconsistency usually points to one of a few root causes: the team grew without establishing shared standards, individual developers imposed personal preferences, or legacy code accumulated different styles without anyone going back to clean things up. Some variation is inevitable, but excessive inconsistency suggests a lack of engineering governance.
Assessors look at both the big picture (architectural patterns, module boundaries, data flow) and the details (variable naming, function structure, error handling, logging). They also check whether automated tooling enforces standards, because standards that rely purely on human discipline during code review are never applied consistently.
How to Implement
Write a coding standards document or style guide for each language and framework you use. Cover naming conventions, code formatting, file and directory organisation, error handling patterns, logging conventions, and preferred approaches for recurring tasks.
Automate enforcement with formatters and linters. Set up Prettier or an equivalent for consistent formatting, and ESLint, Pylint, RuboCop, or similar for language-specific rules. Run these as pre-commit hooks and in CI, blocking merges on violations.
Use architecture-level enforcement tools where they exist. ArchUnit (Java) or dependency-cruiser (JavaScript) can enforce module dependency rules and architectural boundaries, preventing gradual erosion over time.
Document your preferred patterns for common tasks. If there is a standard way to make API calls, handle auth, manage state, access the database, or structure components, write it down and reference it in code reviews. This stops developers from reinventing the wheel in incompatible ways.
Run periodic consistency reviews. Sample different areas of the codebase, check adherence to standards, and plan remediation where things have drifted.
Make coding standards part of onboarding. New team members should understand and adopt the conventions before making significant contributions. Reference standards in their early code reviews.
Be pragmatic. The goal is coherent, readable code - not rigid uniformity. Let standards evolve as the team learns, but manage transitions deliberately rather than letting things drift organically.
Evidence Your Auditor Will Request
- Coding standards or style guide documentation
- Linter and formatter configuration files in the repository
- CI pipeline configuration showing automated standard enforcement
- Code review checklist including consistency checks
- Static analysis reports showing coding standards compliance
Common Mistakes
- No documented coding standards; each developer follows personal preferences
- Standards documented but not enforced by tooling; inconsistency persists
- Different architectural patterns used for the same problem in different modules
- Linter configured with too many disabled rules, effectively bypassing standards
- Standards not updated as the team adopts new patterns; documentation is stale
Related Controls Across Frameworks
| Framework | Control ID | Relationship |
|---|---|---|
| ISO 27001 | A.8.25 | Related |
Frequently Asked Questions
How important is code formatting in due diligence?
Should we reformat the entire codebase before due diligence?
Track Tech Due Diligence compliance in one place
AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.
Start Free Assessment