Chess Game – Help Naming a Possible Movement

cnaming

I'm working on a chess game and have created a base class for game entities and chess pieces, along with an enum for the state of a square, when returned in a collection of possible movements:

public enum MovementValidationResult { None = 0, Safe = 1, Attackable = 2 }
public abstract class GameEntity {
    public bool Alive { get; set; }
    public Vector2 Position { get; set; }
    public Vector2 Rotation { get; set; }
}
public abstract class ChessPiece : GameEntity {
    protected abstract MovementResult[] GetPossibleMovements(Vector2 requestedPosition);
}

When attempting to move a chess piece, I need to get a collection of possible movements, and present them to the client for visual display. The definition of a possible movement is presently limited to:

  • A Vector2 describing the grid coordinates of the square.
  • An educated guess on the result of moving to said square.

For example, I created a CodePen for a coding challenge a while back, and, while I didn't put much thought into it at the time, it visually displays the potential squares a chess piece can move to, and educated guesses for the result of moving to each of those potential squares:

Screenshot of the aforementioned CodePen.

What I'm having trouble with is creating a name for the data structure that describes the resulting state of a square, and as such, the quality of naming for related methods, variables, etc are all impacted. So far, the best I've come up with is MovementResult and while I believe it clearly conveys the data presented; I also believe it to be slightly misleading due to the fact that this is a possible movement, so it isn't the actual result.

However, is there ever a need to really distinguish between possible and actual in such a simple use-case? Also, another reason I'm hesitant is because it sounds like a better name for the MovementValidationResult enum (defined above).

Is MovementResult an acceptable name in this scenario, or should my data structure be named something else entirely?

Note: I didn't exclude a definition for PossibleMovement because no such definition exists yet, and is actually why I'm here.

Best Answer

I will try to answer this and not making an opinionated answer in the way. As I commented, I would start by delving a bit into the game glossary.

After a bit, I came to the conclusion that Candidate board as a possible and virtual state of the board is fair enough. Also Candidate move as a possible and valid movement that leads to a Candidate board.

Variant seems a good fit too, given Wikipedia's definition.

In absence of chess experts, you have to find out names that communicate intent. Or in this case, state. If none of the names likes you, you can add a brief introduction with Javadoc. If you use IDE's it's likely you can read these comments anywhere just moving the cursor over the variable type.

However, is there ever a need to really distinguish between possible and actual in such a simple use-case?

Readability matters. Pick a random name that doesn't express satisfactorily what a method does or what a variable is for, leave the app for the next 6 months, be back then and try to understand the code. Find where things happen without debugging. Or leave others to read your code and see what happens.1

Also, another reason I'm hesitant is because it sounds like a better name for the MovementValidationResult enum (defined above).

Well, you are not a robot. You should be capable of finding out a name that expresses best what MovementValidationResult holds. Swap your "developer hat" with the "gamer" or "chess master" hat. What are None, Safe and Attackable? Vulnerability? Exposure? Is there any term in the glossary to express the same idea?

1:Even if nobody ever reads the code. Getting used to making code readable is the kind of skill you want to develop at all costs. Overall if you are to be professional. I think it was Uncle Bob who wrote once that making code hard to understand was just another way to be disrespectful to your coworkers. I couldn't agree more.

Related Topic