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:

CaseRecord
CaseAssignment
VettingStatus
AccessDecision

Avoid:

CaseData
CaseDtoEntity
ProcessManagerHelper
ThingProcessor

Boolean Names

Boolean names should read naturally:

IsActive
HasExpired
CanApprove
RequiresVetting

Avoid negative booleans where possible:

IsNotEnabled
HasNoAccess

Date and Time Names

Use suffixes to show time semantics:

CreatedAtUtc
ExpiresAtUtc
SubmittedOn
EffectiveFromUtc

Do not use ambiguous names:

Date
Timestamp
Time

API Naming

Request and response models should describe their role:

CreateCaseRequest
CreateCaseResponse
CaseSummaryResponse
UpdateCaseStatusRequest

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