"Implication mechanics" is a term coined by the indie game developer Tim Ruswick to refer to a general phenomenon that seems to occur in not only game design but engineering and design as a whole. Personally, I would summarize the idea he talks about in his video, which I've linked here if you're interested, like this: aspects of how a product or tool is designed always serve to imply a way in which they're intended to be used. This obviously applies to game design, as Tim mentions in his video, but what I want to talk about in this article is how, from my personal experience, this seems to apply to just about every scenario in which you are creating something for others (or your future self) to use, including how you write your code, specifically, the names you choose to give to objects, methods, etc.

This is something that I find very important to consider because one of the most frequent trip-ups I experience and see programmers vent about is using something and discovering that it doesn't function quite how they expected it to. I believe this happens when programmer do not consider what situations the name they've chosen for their method, object, etc. implies it is intended to be used under.

A good example in Hensen Hopper is how, just a bit ago, I renamed a public static method under the Enemy class in Hensen Hopper's codebase that is presently named SetCountToZero() twice due to both ambiguity in what it could represent and ambiguity as to what circumstances it's designed to be used under. I wrote this method, originally, to fix a bug I discovered in the new procedurally generated enemy waves algorithm where, if you died and pressed "retry", enemies would not spawn because the enemy count was still greater than zero as the enemy that kills you neither dies nor despawns. It was an easy fix, really, I just wrote a method to reset the enemy count back to zero and call it on Awake in the EnemySpawnerManager script where this algorithm runs. After I confirmed it was working, I renamed that method twice because I felt the name ResetCount() could potentially be ambiguous for future me if I were to, say, misinterpret that for being a method that returns the number of times the enemies have been reset or something. I changed the name to ResetEnemyCount() first which is no better in that regard and then to SetCountToZero() which I'm satisfied with because that clearly expresses what that method does and implies that whenever you need to make sure your code internally believes there are zero enemies in the scene, call this method.

All of this is to say that the names you choose do not only imply what something is or does but also imply their use cases and when you don't take this aspect of it into account you can and likely will create confusing situations for your teammates or for future you further down the road. I believe a good habit to get into is choosing names for your objects, methods, etc. that not only clearly express what it is/does but also imply what situations they're designed to be used under to help minimize confusing situations where you think something will do something but it turns out it does something else you weren't expecting.

That's all for this infodump. Thanks for taking the time to read this if you did!