# Coding Standards

Inline with the Engineering Principle [**We Care About Quality**](/standards/engineering/engineering-principles/2-quality), this folder contains coding standards for the most common languages and frameworks in use at Audacia:

- [C# Standards](/standards/engineering/coding-standards/csharp)
- [HTML and CSS](/standards/engineering/coding-standards/html-and-css)
- [TypeScript Standards](/standards/engineering/coding-standards/typescript)
- [SQL Coding Standards](/standards/engineering/coding-standards/sql)

Separate [Automated Testing](/standards/engineering/engineering-principles/5-automated-testing) and [Secure Coding Standards](/standards/engineering/engineering-principles/7-security-and-availability/secure-coding-standards) are also defined.

## Language Agnostic Standards

### Codebases must be consistent · CODING-01.1 · **MUST** · **DEV/TEST**

Consistency within a codebase is extremely important. Even if the code does not necessarily follow best practices, it may make things worse to introduce inconsistency by only changing a small section of it.

For example, if a codebase currently uses spaces for indentation, don't start using tabs in some files (and vice-versa).

See [Google's style guide](https://google.github.io/styleguide/htmlcssguide.html#Parting_Words) for more information.

### Data must not be hard-coded · CODING-01.2 · **MUST** · **DEV/TEST**

Values should be configurable, e.g. read from a configuration file or a database, rather than hard-coding in the application code.

Examples of values to particularly avoid hard-coding are:
- Email addresses to receive error or alert emails
- Something liable to change outside of the control of the application, such as the VAT rate