Cygnus Dynamics — Coding Standards
Welcome to the Cygnus Dynamics Coding Standards — the single source of truth for how we write, review, and ship code across all our technology teams.
Who is this for?
Every engineer at Cygnus Dynamics is expected to read and follow these standards. They apply to all production code and are enforced during code review and through automated CI checks.
Getting Started
If you are new to Cygnus Dynamics, read the sections in this order:
| Step | Read | Why |
|---|---|---|
| 1 | General Principles | Universal rules that apply to every line of code you write |
| 2 | Your language section | The specific standards for your primary stack |
| 3 | Testing Standards | How we write and enforce tests across all languages |
| 4 | Git & Code Review | Commit format, branch naming, and PR process |
Not sure where to start?
Start with General Principles. Every rule there applies regardless of language or framework — they are the foundation everything else builds on.
What are coding standards?
Coding standards are rules, conventions, and guidelines that define how code should be written and maintained. They provide a consistent framework for development teams to write, format, and organise software in a way that ensures quality, security, maintainability, and scalability.
Without standardisation, engineers write code in their own individual styles. Over time, collaboration slows as team members spend unnecessary hours untangling each other's logic. Delivery timelines slip, costs increase, and technical debt accumulates.
When implemented effectively, strong coding standards improve team workflow, increase productivity, and support compliance with security and privacy requirements.
Why coding standards matter
Coding standards simplify and organise every stage of the software development lifecycle:
- Development: Consistency across teams makes code easier to read, understand, and debug.
- Testing and QA: Standardised structure and naming conventions enable more effective unit testing and faster defect identification.
- Code review: Reviewers focus on logic and design — not formatting, naming disputes, or style preferences.
- Project management: A standardised codebase lets teams track progress and quality more accurately across sprints and modules.
- Knowledge sharing: Shared conventions reduce onboarding time. New developers do not need to navigate inconsistent styles to become productive.
Benefits
| Benefit | Description |
|---|---|
| Improved consistency | A unified codebase reduces errors caused by conflicting practices and produces more reliable releases |
| Higher code quality | Standards incorporate best practices for error handling, input validation, and resource management |
| Increased efficiency | Less time fixing inconsistent or duplicated code — more time delivering features |
| Faster onboarding | New developers become productive quickly; departing team members leave maintainable work behind |
| Improved security | Secure coding practices reduce vulnerabilities and support compliance with data privacy regulations |
| Reduced technical debt | Standards keep the codebase predictable, maintainable, and easier to extend over time |
| Long-term cost savings | Fewer defects, less rework, lower maintenance overhead, and minimised compliance risk |
What's covered
| Section | What it covers |
|---|---|
| General | Universal principles that apply to all languages and frameworks |
| Java | Naming conventions, class structure, exception handling, and best practices |
| Python | Naming, formatting, type hints, docstrings, and Pythonic patterns |
| C# | Naming conventions, formatting, language features, and best practices |
| Go | Naming conventions, formatting, language features, and best practices |
| JavaScript | Naming conventions, formatting, language features, and best practices |
| TypeScript | Naming, configuration, types and interfaces, and best practices |
| React | Component rules, hooks, performance, and folder structure |
| Node.js | Project structure, async patterns, error handling, API design, and security |
| SQL | Naming, query formatting, optimisation, and schema design |
| Testing | Testing pyramid, frameworks by language, coverage requirements, and enforcement |
| Git & Code Review | Commit messages, branch naming, pull request process, and review etiquette |
How standards are enforced
Enforcement is shared between automated tooling and human reviewers. Automated checks handle the mechanical rules so that reviewers can focus on logic, design, and correctness.
Automated enforcement
| Gate | What it checks | When it runs |
|---|---|---|
| Pre-commit hooks | Linting and formatting (ESLint, Prettier, Ruff, Checkstyle) | On every git commit |
| CI pipeline | Tests, coverage thresholds, security scans | On every pull request |
| Merge gate | All CI checks must pass; minimum 1 approval required | Before any PR is merged |
| Nightly pipeline | End-to-end tests against staging | Every night |
Human enforcement
- Code reviewers are expected to identify and flag violations of these standards during review.
- Pull requests that do not meet coding standards or fail CI checks will not be approved or merged.
- Violations are flagged as blocking or non-blocking review comments — see Pull Requests for the distinction.
- Repeated violations are escalated to the respective Tech Lead for further guidance.
CI gates are not optional
A passing CI pipeline is a prerequisite for merge — not a suggestion. If the pipeline is red, the PR does not merge. No exceptions.
Keeping standards up to date
These standards are a living document. They are reviewed and updated as languages, frameworks, and best practices evolve.
- Proposed changes are raised in #coding-standards on Slack.
- Significant changes are reviewed and approved by Tech Leads before being published.
- Engineers are expected to stay current — breaking changes to standards will be communicated via Slack and the team all-hands.
Questions or suggestions? Raise it in #coding-standards on Slack or speak to your Tech Lead.