# Naming

Naming is perhaps one of the most important skills for writing clean code. Upon first read, a name should indicate to developers the following things:

Why the code exists?
What is the purpose of the code?
How is the code used?

# General

The following are some general rules about code naming that we follow:

They must be meaningful

Bad

function isBetween(a1: number, a2: number, a3: number): boolean {
                   ^-          ^-          ^- 
    return a2 <= a1 && a1 <= a3
}

Good

function isNumberBetween(value: number, lowerBound: number, upperBound: number): boolean {
           ^-----        ^----          ^---------          ^---------
    return lowerBounds <= value && value <= upperBound
}

They must be pronounceable

Bad

export type NetworkSts = {
    mps?: number
    health?: number
    healthTxt?: NetworkStsHealthTxt
    curMilestone?: number
}

Good

export type NetworkStatus = {
    messagesPerSecond?: number
    health?: number
    healthText?: NetworkStatusHealthText
    currentMilestone?: number
}

They must NOT be mental mappings

Bad

const ns = getNetworkStatus()
const nht = getTextForNetworkHealth(ns)

Good

const networkStatus = getNetworkStatus()
const networkHealthText = getTextForNetworkHealth(networkStatus)

They must NOT add unneeded context

Bad

type Profile {
    profileName: string
    profileType: ProfileType
    profileStorageDirectory: string
}

Good

type Profile {
    name: string
    type: ProfileType
    storageDirectory: string
}

# Files

# TypeScript

All TypeScript filenames are in kebab-case, e.g. deep-link-handler.ts. Some filenames may include an optional file type specifier, e.g. deep-link.store.ts.

# Svelte

Svelte component names / filenames use the following conventions:

Must be written in PascalCase
Must be suffixed with the component's type, e.g. LedgerTransactionPopup since it is a popup component (this applies to all component types, i.e. routers, views, inputs, buttons, modals, etc.)

# Acronyms

When a variable name contains an acronym, the first letter must be uppercase and the rest lowercase. This convention creates more readable names particularly in the circumstances where another word follows the acronym.

Bad

type UTXOInput {
   // ... 
}

Good

type UtxoInput {
    // ...
}

# Code

# Booleans

All objects, functions, stores, i.e. code components of boolean type must be prefixed with being verbs (e.g. "is", "are", "has", "will", "can", "should", "must")

Bad
```
const enabled = false
```
Good
```
const isEnabled = false
```
ℹ️ This also pertains to any functions that are of boolean type; isStrongholdLocked() is more self-documenting than strongholdLocked().

All booleans must use positive names

Bad

const isNotEnabled = false

Good

const isEnabled = false

# Constants

All constants must be in SCREAMING_SNAKE_CASE

Bad

const maxNumIotas = 2_779_530_283_277_761

Good

const MAX_NUM_IOTAS = 2_779_530_283_277_761

# Enumerations

All enum and enum variant names must be in PascalCase

Bad

enum profileType {
    stronghold,
    ledger,
}

Good

enum ProfileType {
     ^      ^
    Stronghold,
    ^ 
    Ledger,
    ^
}

All enum names must be singular

Bad

enum ProfileTypes {
    Stronghold,
    Ledger,
}

Good

enum ProfileType {
                ^
    Stronghold,
    Ledger,
}

# Functions

All function names must be in camelCase

Bad

function Some_Function(): void {
    // ...
}

Good

function someFunction(): void {
         ^
}

User action handlers must start with on and should end in Click. They mustn’t end in Click when the user action can be triggered by pressing enter button as well.

.Bad
```
function handleCreateProfileClick(): void {
    // ...
}
```
Good
```
function onCreateProfileClick(): void {
    // ...
}
```

Handlers that aren’t directly triggered by user actions must start with handle

Bad

function onTransactionInclusionEvent(): void {
    // ...
}

Good

function handleTransactionInclusionEvent(): void {
    // ...
}

# Interfaces

All interface names must be in PascalCase preceded with an I

Bad

interface strongholdApi {
    // ...
}

Bad

interface StrongholdApi {
    // ...
}

Good

interface IStrongholdApi {
          ^
}

# Types

All type names must be in PascalCase

Bad

type profile {
    // ...
}

Good

type Profile {
     ^
}