> For the complete documentation index, see [llms.txt](https://framework.aic.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://framework.aic.io/technical-guidelines-code-standards-and-tech-stack/c-code-standards/naming-standards.md).

# Naming Standards

## Purpose

Names are part of design. Good names reduce comments, improve comprehension and make code review easier.

## General Rules

* Use clear, intention-revealing names.
* Prefer business language over technical shorthand.
* Avoid abbreviations unless widely understood.
* Avoid Hungarian notation.
* Avoid meaningless suffixes such as `Data`, `Info`, `Manager` or `Helper` unless precise.
* Use consistent naming across API, domain, database and UI where possible.

## C# Naming Table

| Element        | Convention                   | Example                                           |
| -------------- | ---------------------------- | ------------------------------------------------- |
| Namespace      | PascalCase                   | `Aic.Cases.Application`                           |
| Class          | PascalCase                   | `CaseAssignmentService`                           |
| Interface      | PascalCase with I prefix     | `ICaseRepository`                                 |
| Method         | PascalCase                   | `AssignCaseAsync`                                 |
| Async method   | PascalCase with Async suffix | `SaveChangesAsync`                                |
| Property       | PascalCase                   | `CreatedAtUtc`                                    |
| Field private  | `_camelCase`                 | `_caseRepository`                                 |
| Constant       | PascalCase                   | `MaximumRetryCount`                               |
| Local variable | camelCase                    | `caseRecord`                                      |
| Parameter      | camelCase                    | `caseId`                                          |
| Type parameter | T prefix                     | `TResponse`                                       |
| Test class     | ClassUnderTestTests          | `CaseServiceTests`                                |
| Test method    | Behaviour style              | `AssignCase_WhenUserIsUnavailable_ReturnsInvalid` |

## Domain Naming

Domain classes should use customer and business vocabulary.

Prefer:

```csharp
CaseRecord
CaseAssignment
VettingStatus
AccessDecision
```

Avoid:

```csharp
CaseData
CaseDtoEntity
ProcessManagerHelper
ThingProcessor
```

## Boolean Names

Boolean names should read naturally:

```csharp
IsActive
HasExpired
CanApprove
RequiresVetting
```

Avoid negative booleans where possible:

```csharp
IsNotEnabled
HasNoAccess
```

## Date and Time Names

Use suffixes to show time semantics:

```csharp
CreatedAtUtc
ExpiresAtUtc
SubmittedOn
EffectiveFromUtc
```

Do not use ambiguous names:

```csharp
Date
Timestamp
Time
```

## API Naming

Request and response models should describe their role:

```csharp
CreateCaseRequest
CreateCaseResponse
CaseSummaryResponse
UpdateCaseStatusRequest
```

Do not expose database entity names unless they are truly the contract model.