这是一个很常见的情况。由于是个人开发（Unity），所以无论写什么代码都是被允许的。

例子1：是否可见

最初我想到的是IsVisible，但是这个命名会变成“这个物体本身能够被看见吗”（类似于enabled），而Is系列通常用于表示“状态的可行性”（这个对象现在是怎样的），根据经验，通常会将其应用到属性上，而将Is添加到方法名中则在心理上有些抵抗。

接下来我想到的是CanBeSeenFrom(Player)。这个命名似乎也在虚幻引擎中使用（https://docs.unrealengine.com/5.0/en-US/API/Runtime/AIModule/Perception/IAISightTargetInterface/CanBeSeenFrom/），所以我认为这个命名暂时还可以。

Can系列用于表示“动作的可行性”（动词紧跟其后），所以我认为它非常适合表示“看见”这个动作的可行性。

但是，分解之后它变成了Can Be Seen From这四个词，所以没有像IsVisible那样直观明了。

因此，最后我还是不知道具体该怎么命名，就这样被搁置了下来。

例子2：静态数据库

让我们假设正在制作游戏。
在游戏中，我们希望创建一个能够储存所有舞台数据的类。
（请先忽略需要在需要时加载的事情）

首先，StageManager是不可接受的。虽然这会得罪Unity，但Management表示的是”管理”，如果用于游戏本身(Game)，也可以被视为合适的选择。
然而，我们想要做的并不是”管理”舞台的进程，而是将数据”存放”在那里。
接下来，我们想到的是”Database”，但这也不合适。Database表示的是”可修改的动态数据库”这样的单词，不适合存放像舞台ID这样很少改变的信息。
换句话说，如果是要”存放”的话，”Store”（作为动词）可能会更合适……因此，最后我们决定使用”StageStorage”。

另一种选项是将静态信息保存下来，这样做是缓存的工作，所以也可以称之为”StageCache”。
不过，这个名字可能会让人误以为是用来缓存舞台的游戏内容和图片的类，所以如果要使用”Cache”的话，可能会变成”StageInfoCache”或”StagePropertyCache”之类的命名。
真是棘手。

实用性

假设在Unity中存在一种计算距离的机制，抛开这个问题不提，我们希望进行距离计算。

「距离」也许更合适。

不过话说回来，我们必须给外围的类取一个名字。
但是我并不想把它叫做”~~Helper”，这是我的个人意见。
那么作为外围类名，合适的是”MathProvider”，对吧？
但是”Provider”这个名字太大了。好像这个类提供的就是一切一样（我这么认为），所以最后还是决定叫”MathHelper”吧。

该怎么办？

参考先人的信息来命名类。