Object Oriented JS - ready for review

[LuckyDnepr]

Object Oriented JS

Demo |
Code base

The code is submitted in a dedicated feature branch.

Only code files are submitted.

Please, review.

[github-actions]

Hey!

Congratulations on your PR! 😎😎😎

Let's do some self-checks to fix most common issues and to make some improvements to the code before reviewers put their hands on the code.

Go through the requirements/most common mistakes listed/linked below and fix the code as appropriate.

If you have any questions to requirements/common mistakes feel free asking them here or in Students' chat.

When you genuinely believe you are done put a comment stating that you have completed self-checks and fixed code accordingly.

Also, be aware, that if you would silently ignore this recommendation, a mentor can think that you are still working on fixes. And your PR will not be reviewed. 😒

This PR contains irrelevant files.

You can see this under Files changed tab (you will find a couple of helpful tabs right under the PR title).

Most likely, you added all files from your project, not only required and sufficient code review as instructed in section B123 of submission instructions. Also read an important note therein.

Why we want only few files?

1. It helps code reviewers to focus on code you authored and have the workspace uncluttered with irrelevant images and transpiled files.
2. This keeps homeworks repository small.
   For example, images add to the weight of the repo and will affect download/upload time for mentors and other students. We all care about others' time.

Please fix this issue by removing irrelevant files and add a comment stating that you did this.

Universal recommendations:

• Give variables and functions meaningful names. Avoid generic names like item, element, key, object, array or their variations. Exception: helper functions that are specifically and intentionally designed to be multipurpose.
• Function names should start with a verb as they denote actions; variables are normally nouns; boolean variables/functions start with is, does, has etc; variable containing multiple entities and functions returning lists contain entity name in plural form.
• Have consistent code style and formatting. Employ Prettier to do all dirty work for you.
• Use common sense or seek for an advice whenever requirements look ambiguous or unclear.

Also take a note of the requirements above and follow them in all your future projects.

By the way, you may proceed to the next task before this one is reviewed and merged.

Sincerely yours,
Submissions Kottachecker 😺

[github-actions]

Hey!

Congratulations on your PR! 😎😎😎

Let's do some self-checks to fix most common issues and to make some improvements to the code before reviewers put their hands on the code.

Go through the requirements/most common mistakes listed/linked below and fix the code as appropriate.

If you have any questions to requirements/common mistakes feel free asking them here or in Students' chat.

When you genuinely believe you are done put a comment stating that you have completed self-checks and fixed code accordingly.

Also, be aware, that if you would silently ignore this recommendation, a mentor can think that you are still working on fixes. And your PR will not be reviewed. 😒

Frogger Arcade Game -- JS OO exercise check list

Relates to Object-Oriented JavaScript task.

Check-list - definition of done

• employ ES6 features like const, let etc. (with exclusion of ES6 class syntax)

• the code is very DRY

• Requirements re Constants:

  • all numbers like block dimensions, initial locations are defined as named constants (e.g. const STEP = 101;) as otherwise numbers scattered across code base look cryptic; named constants add semantic meaning and improve readability
  • every number that has a semantic purpose (like those listed above) should be defined as constants; think of how your code reads - the closer to plain English the better
  • there are core constants and derived constants
    (e.g. derived constant const FIELD_WIDTH = BLOCK_WIDTH * BLOCKS_NUMBER;)
  • arrays of constants are also constants
    (e.g. const INITIAL_POSITIONS = [1,2,3,4].map(rowNumber => rowNumber * BLOCK_HEIGHT);)
  • const objects help organizing and structure const data even better
    (e.g. const PLAYER_CONF = { initialPosition: {x: 1, y: 5}, sprite: '...', ...etc... };

• Requirements re OOP:

  • OO is implemented using JS prototype chain object model (not ES6 classes syntax)
  • classes do not refer to any global variables, like global variable player, which is an instance of Player class
    (referring to global constants and globals provided by the gaming platform like Resources is OK);
    Hint: pass Player instance as an argument to every enemy
  • Separation of Concerns principle is followed
    (e.g. update method does only rendering and doesn't contain any unrelated inline code; for example collision check is defined as a dedicated method and only called from inside update)
  • Nice To Have: properties common for some classes are generalized into a base class
    (e.g. there is Character base class, which is extended by Enemy and Player classes)
  • class extension is implemented using Subclass.prototype = Object.create(Superclass.prototype), not Subclass.prototype = new Superclass(params);; Helpful resource

• Most common mistakes

  • Make sure target = condition ? valueWhenConditionTrue : valueWhenConditionFalse is used instead of condition ? target = valueWhenConditionTrue : target = valueWhenConditionFalse; Conditional (ternary) operator

Universal recommendations:

• Give variables and functions meaningful names. Avoid generic names like item, element, key, object, array or their variations. Exception: helper functions that are specifically and intentionally designed to be multipurpose.
• Function names should start with a verb as they denote actions; variables are normally nouns; boolean variables/functions start with is, does, has etc; variable containing multiple entities and functions returning lists contain entity name in plural form.
• Have consistent code style and formatting. Employ Prettier to do all dirty work for you.
• Use common sense or seek for an advice whenever requirements look ambiguous or unclear.

Also take a note of the requirements above and follow them in all your future projects.

By the way, you may proceed to the next task before this one is reviewed and merged.

Sincerely yours,
Submissions Kottachecker 😺

[LuckyDnepr]

I delete irrelevant files and do self-checks.
Please review.

[OleksiyRudenko]

@LuckyDnepr a really good job!
Let's polish it.

[OleksiyRudenko]

Comments like these 2 normally mean that someone isn't happy with variable names.
It makes sense to make variable names more descriptive rather than adding comments for this purpose.
They need to read good not only at the definition but at points of usage as well.

[OleksiyRudenko]

What is 200 and 405?
If I change the playfield parameters how do I calculate those?

[OleksiyRudenko]

What is 62, 145 and 228?
If I change the playfield parameters how do I calculate those? Any dependencies on row number?
Note also that using calculations and methods like map are legal at constant definition phase.

[OleksiyRudenko]

So, instead of having descriptive names / constants we add comments. Not a good practice

[OleksiyRudenko]

Confusing fragment. Reads like "end game? - no!". Comment says otherwise. Would make more sense to either rename the function or change its argument interpretation.

[OleksiyRudenko]

We are in the context of player. Player is redundant here. If player would move enemies then moveEnemyToStart would make sense.

[OleksiyRudenko]

What are 5, 4 and 10?

[OleksiyRudenko]

Look how this._isFrozen would read almost plain English.

[OleksiyRudenko]

Unfreezing kinda implies that this process will end sometime later.

[OleksiyRudenko]

If we need a comment this means the code is not expressive enough. Function names are normally descriptive.

[LuckyDnepr]

I think I followed all the recommendations.
Please, re-review.

[OleksiyRudenko]

@LuckyDnepr excellent job!