HiveBrain v1.2.0
Get Started
← Back to all entries
patternjavascriptMinor

JSDoc for TCG game entity configuration

Submitted by: @import:stackexchange-codereview··
0
Viewed 0 times
tcggamejsdocforconfigurationentity

Problem

The Cardshifter team has been working at "translating" a very complex Java class into JavaScript, to make it more accessible to somebody who would want to fork the game and make their own modification, which is an objective that's been close to our hearts since the very beginning (for the game to be very "moddable").

I started writing JSDoc into what we have adapted to JS so far. I have never written JSDoc before, hence I am seeking advice for improvement. The documentation is purposefully worded to be read and understood by a beginner who is just starting on the project. My main concerns:

-
Is it clear?

-
Is it redundant/too much?

-
Is my use of @implements and @param good?

Here is the original PhrancisGame.java class.

Here is the documentation and code so far:

```
/**
* Replicates the logic located in PhrancisGame.java
* This module is to set up all the core game components required to start a game
* Location of original Java file:
* cardshifter-core/src/main/java/net/zomis/cardshifter/ecs/usage/PhrancisGame.java
* @module PhrancisGame
*/

/** Card zones and owners */
var ZoneComponent = Java.type("com.cardshifter.modapi.cards.ZoneComponent");
/** Players & win/lose logic */
var PlayerComponent = Java.type("com.cardshifter.modapi.base.PlayerComponent");
/** Build decks using min/max size and cards */
var DeckConfigFactory = Java.type("net.zomis.cardshifter.ecs.config.DeckConfigFactory");
/** Potential configurations for players/entities. Primarily stores DeckConfigs */
var ConfigComponent = Java.type("net.zomis.cardshifter.ecs.config.ConfigComponent");
/**
* Enum that represents various player resources:
* MAX_HEALTH, SNIPER, DOUBLE_ATTACK, TAUNT, DENY_COUNTERATTACK, HEALTH, MANA, MANA_MAX, SCRAP,
* ATTACK, MANA_COST, SCRAP_COST, ENCHANTMENTS_ACTIVE, SICKNESS, ATTACK_AVAILABLE
* @implements ECSResource
*/
var PhrancisResources = Java.type("net.zomis.cardshifter.ecs.usage.PhrancisGame.PhrancisResources");
/**
* Stores resources for e

Solution

Is it clear?

No. It would be easier to read with more vertical spacing (blank lines),
for example after each /** ... */ + variable.


Is it redundant/too much?

Yes.
I don't know of a precedent of documenting variables.
For example:

/**
 * @param {Object} owner - Owner of the ZoneComponent.
 * @param {string} name - Name of the ZoneComponent.
 */
var zone = new ZoneComponent(neutral, "Cards");


The documentation of the ZoneComponent constructor should be written where it's defined, not here where you use it.

I think you should delete most of the documentation in the posted code,
keeping only:

  • the documentation at the top of the file



  • the documentation of the functions you defined yourself (declareConfiguration, addCards, ...)




Is my use of @implements and @param good?

The typical use of @implements is to mark classes that implement some interface. But you marked instances.
Instances don't implement interfaces, they use them.

The use of @param is good.

Code Snippets

/**
 * @param {Object} owner - Owner of the ZoneComponent.
 * @param {string} name - Name of the ZoneComponent.
 */
var zone = new ZoneComponent(neutral, "Cards");

Context

StackExchange Code Review Q#87894, answer score: 5

Revisions (0)

No revisions yet.