My Clean Code - Naming

Clean Coding Practices Overview

This blog is just simply my rules for clean code, It will cover the clean code conventions I use in the naming of everything inside my games, while using typescript as a basis, this can be used in any language.

Names must reveal intent

avoid vague or single-letter names unless the scope is tiny and instantly obvious.

Bad

Good

Why

The second example tells you exactly what each value means without needing comments or extra code tracing.

---

Names must not create disinformation

Do not use names that imply the wrong type, shape, or behavior.

Bad

Good

Why

player_list sounds like an ordered Array, but the value is actually a Dictionary keyed by player name. That mismatch makes readers assume the wrong thing before they even inspect the code. Honest names reduce confusion, cut down tracing, and protect trust in the codebase.

---

Names must explain themselves before implementation

Do not make readers open the function body just to learn what the game logic actually does.

Bad

Good

Why

`doThing` and `run` say nothing about the actual gameplay behavior. A reader has to inspect the implementation to discover that one function filters alive enemies and the other extracts item sell values. `getLivingEnemies` and `getItemSellValues` reveal the game logic immediately, which makes combat, loot, and inventory code much easier to trust and maintain.

---

Names must sound like real gameplay language

Use names that developers can say out loud, discuss naturally, and understand without decoding abbreviations.

Bad

Good

Why

`plyrXpRwdByMobId` and `calcXpRwd` force the reader to decode compressed shorthand before they can understand the gameplay logic. `experienceRewardByEnemyId` and `getExperienceRewardForEnemy` sound like real language, which makes the code easier to read, easier to discuss in a team, and easier to trust during combat and progression work.

---

Names must be searchable

Use names you can quickly find in the codebase. Avoid tiny or generic names when the value matters beyond a tiny local scope.

Bad

Good

Why

`data` and `get` are too generic to search for with confidence in a real game codebase. They will collide with dozens of unrelated results and force readers to rely on surrounding code for meaning. `weaponDamageByItemId` and `getWeaponDamageByItemId` are specific, searchable, and easy to trace when you are debugging combat, balancing items, or refactoring inventory systems.

---

Names must describe gameplay intent, not the variable type

Do not encode the type into the name when the language and tooling already tell you that. Use the name to explain the game meaning instead.

Bad

Good

Why

`iDamage`, `bIsCritical`, and `arrLootDrops` spend naming space on type information that TypeScript and your editor already know. That leaves less room for the actual gameplay meaning. `damageAmount`, `isCriticalHit`, and `lootDropIds` tell the reader what the values represent in combat and loot logic, which makes the code easier to read, discuss, and maintain.

---

Names must not force decoding

Do not compress gameplay meaning into cryptic shorthand. A good name should read clearly the first time.

Bad

Good

Why

`dmgModCfg` and `calcAtkMod` make the reader stop and decode shortened words before they can understand the combat logic. `damageModifierByEquipmentId` and `getDamageModifierForEquipment` say exactly what the data and function represent, which makes balancing, debugging, and combat tuning much easier to follow.