As others have commented, there's no single strategy for this. Personally, I prefer the term "equipment" for items that the player can equip (such as armor and weapons), not for consumables (such as potions). However, you should take your in-game terminology into consideration. It's generally a good idea to make developer terminology reasonably consistent with in-game terminology so that your team members don't get confused.
Here's an example of a frustrating scenario: you have a base class Item
, and several child classes such as Weapon
, Armor
, Consumable
, Key
, Ammo
. Then your boss/client/UX team decides that within the game UI, "Equipment" will be a term for weapons and armor, and "Item" will be a blanket term for all other things that can go into your inventory, such as consumables, keys, and ammo. Now, whenever someone talks about an "item", you have to ask for clarification - are they referring to the Item
class or the "Item" category in the game?
Another way you can avoid confusion is to use developer terminology that would never appear in an actual game. For example, in the Unity engine, any object that can be placed in the world is a GameObject
. If I recall correctly, in the Source engine, any object that can be placed in the world is an Entity
. In some engines and frameworks, any type of character is an Actor
. Because these terms are never used in actual games, they help to avoid ambiguity in developer conversations.
With that in mind, you could consider base class names like Equipable
, Holdable
, PlayerItem
that would definitely never appear as in-game terminology.
It's not always practical, but when possible you should try to work out all of your terminology early on and try to make it consistent between the code and in-game UI to avoid confusion/ambiguity.