As you noticed: it's hard to force comments when the code is written well. Once you get rid of magic values, create descriptive names for both variables and methods and make sure each method does one thing you have basically reached a so-called self-documenting code.

And that's good: this is the kind of code you want to reach. However, teachers are teachers and they won't always recognize your awesomeness.

Luckily for you there are two main categories of commenting.

Many new programmers comment the what: "what does the code do?". These are very uninteresting comments, an example could be this:

// In case the mouse moved
public void mouseMoved(MouseEvent e) {
    mouseY = e.getY(); // Update the mouse's Y-position
}

These type of comments just reiterate what we can already read very clearly from the code itself (see: self-documenting code).

The other type of comments elaborate on the why. These are comments that explain your reasoning behind a bit of code, something that is a lot harder to express in code.

Take for example this piece of code:

private void updatePlayerScore(GLabel playerScore) {
    playerScore.setLabel(String.valueOf(PLAYER_SCORE));
    playerScore.setLocation(MODIFIER * WIDTH + 10, getHeight() - 10);
}

When I read this, I ask myself the question "Why did the location of that score get changed?". This is an excellent opportunity for you to add a comment why that is:

// Change location because the playfield changed size
private void updatePlayerScore(GLabel playerScore) {
    playerScore.setLabel(String.valueOf(PLAYER_SCORE));
    playerScore.setLocation(MODIFIER * WIDTH + 10, getHeight() - 10);
}

Now I will immediately know what your intentions were and the general idea behind your approach is clearer. I'm certain your teachers will appreciate such informative commenting when they have to look through a multitude of assignments, many which will not have gone through a review.

Sidenotes

Just to remark a few other things:

• Still some magic values left at the bottom of the file
• Many public variables. Some might be intended like that, but your Random instance shouldn't be amongst them.

As you noticed: it's hard to force comments when the code is written well. Once you get rid of magic values, create descriptive names for both variables and methods and make sure each method does one thing you have basically reached a so-called self-documenting code.

And that's good: this is the kind of code you want to reach. However, teachers are teachers and they won't always recognize your awesomeness.

Luckily for you there are two main categories of commenting.

Many new programmers comment the what: "what does the code do?". These are very uninteresting comments, an example could be this:

// In case the mouse moved
public void mouseMoved(MouseEvent e) {
    mouseY = e.getY(); // Update the mouse's Y-position
}

These type of comments just reiterate what we can already read very clearly from the code itself (see: self-documenting code).

The other type of comments elaborate on the why. These are comments that explain your reasoning behind a bit of code, something that is a lot harder to express in code.

Take for example this piece of code:

private void updatePlayerScore(GLabel playerScore) {
    playerScore.setLabel(String.valueOf(PLAYER_SCORE));
    playerScore.setLocation(MODIFIER * WIDTH + 10, getHeight() - 10);
}

When I read this, I ask myself the question "Why did the location of that score get changed?". This is an excellent opportunity for you to add a comment why that is:

// Change location because the playfield changed size
private void updatePlayerScore(GLabel playerScore) {
    playerScore.setLabel(String.valueOf(PLAYER_SCORE));
    playerScore.setLocation(MODIFIER * WIDTH + 10, getHeight() - 10);
}

Now I will immediately know what your intentions were and the general idea behind your approach is clearer. I'm certain your teachers will appreciate such informative commenting when they have to look through a multitude of assignments, many which will not have gone through a review.

Member order

Regarding your edit on method order (which I changed to member order to get some other things as well): usually I would point you to the Java Code Conventions but appearantly they all give a 404 right now. However from the top of my head, this is the order of which a class' members should appear:

• Constants
• Static variables
• Instance variables
• Static constructor
• Initializer block
• Constructor
• Methods

The actual order of the content of each type is not important (except variables that use another variables: they have to be defined in the right order).

Sidenotes

Just to remark a few other things:

• Still some magic values left at the bottom of the file
• Many public variables. Some might be intended like that, but your Random instance shouldn't be amongst them.