patternjavaMinor
Small Mario game
Viewed 0 times
gamesmallmario
Problem
I have a little Mario game I started working on and I realized that its format is very messy. Can anyone critique my code on how to make it better, faster, neater, and easier to access?
frame.java
board.java
```
package EvilMario; //Include this class in the EvilMario game package
import java.awt.*;
frame.java
package EvilMario; //Include this class in the EvilMario game package
import javax.swing.JFrame; //Import the JFrame
public class frame { //Run this class to run the game
public static void main(String[] args) { //The first method called by java
JFrame frame = new JFrame("EvilMario v.1.0.2 by Max Mastalerz"); //Create JFrame called frame
frame.getContentPane().add(new board()); //Go to board class
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); //Make frame close on X click
frame.setSize(600,413); //Set the frame size to the size of the background
frame.setResizable(false); //Make sure the user can't resize the frame
frame.setLocation(20, 50); //Place the frame in a nicer position
frame.setVisible(true); //Make the frame visible
int frameWidth = frame.getContentPane().getWidth();
int frameHeight = frame.getContentPane().getHeight();
}
}board.java
```
package EvilMario; //Include this class in the EvilMario game package
import java.awt.*;
Solution
There's two glaring issues jumping into my face in this code. They are both somewhat beginner mistakes, so don't be sad :)
Commenting:
"I commented a lot of lines so you can understand the game logic"
That is not the purpose of comments. This is a common misconception, especially when beginning programming. When writing code, you should strive to comment the lest possible.
There are two exceptions to this rule:
-
Mandatory comments:
This especially concerns code you write for companies. There may be some legal requirements that need to be commented. Prominent example: License and author.
-
Javadoc:
When writing code for public usage, you should at some point explain what the publicly visible methods do. This is done using Javadoc, a special kind of comments.
Other than that, most comments are pure noise.
I see that myself ;) It's the same for all the comments you placed on the side of your files. It needlessly lengthens lines and makes your code much harder to read effectively :(
Naming:
Part I: Conventions
Java has some naming conventions.
-
"Classes should be named in
-
"Fields and methods should be named in
-
Your Enum-type is named in
Part II: Variable names:
All these variable names are less than optimal... what does
What does
what is dx, nx, nx2?
You see what I am getting at? These variable names need to be more descriptive.
Final words:
Your code is showing you are a beginner in Java. That's not a bad thing, but your style is somewhat messy. Improve your variable naming and follow the Java-conventions. Comment less. Try to make your code so easy to read, that commenting feels useless, or better even, a hindrance for reading.
Commenting:
"I commented a lot of lines so you can understand the game logic"
That is not the purpose of comments. This is a common misconception, especially when beginning programming. When writing code, you should strive to comment the lest possible.
There are two exceptions to this rule:
-
Mandatory comments:
This especially concerns code you write for companies. There may be some legal requirements that need to be commented. Prominent example: License and author.
-
Javadoc:
When writing code for public usage, you should at some point explain what the publicly visible methods do. This is done using Javadoc, a special kind of comments.
Other than that, most comments are pure noise.
//Include this class in the EvilMario game packageI see that myself ;) It's the same for all the comments you placed on the side of your files. It needlessly lengthens lines and makes your code much harder to read effectively :(
Naming:
Part I: Conventions
Java has some naming conventions.
-
"Classes should be named in
PascalCasing". Your classes all begin with a lower-case letter. If you create a new class in eclipse, and the first letter is lowercase, the "Create Class" dialog will produce a warning: "Lower case type names are discouraged in Java".-
"Fields and methods should be named in
camelCase". Most of your fields are named in PascalCase. This partly is connected to the fact, that your types are named camelCase already. If you swap that, your code becomes much more Java-like ;)-
Your Enum-type is named in
ALLCAPS. Enums belong to the types. They also are supposed to be named in PascalCase. But your enum values are nicely ALL_CAPS. I like that. (Take with a grain of salt, that is my personal preference)Part II: Variable names:
int x, dx, y, nx, nx2;
Graphics g;
Font fnt0, fnt1, fnt2;All these variable names are less than optimal... what does
fnt mean? (Font, I know..) Which fnt is which font, where should they be used?What does
g mean? g-force? \$9,81 \dfrac{m}{s^2}\$ (gravitational factor of earth)?what is dx, nx, nx2?
You see what I am getting at? These variable names need to be more descriptive.
fnt0 --> arialLarge
fnt1 --> arialMedium
fnt2 --> arialSmall
g --> graphicsDevice
dx --> deltaX / xChange
nx --> newX (?)
nx2 --> secondNewX(?)Final words:
Your code is showing you are a beginner in Java. That's not a bad thing, but your style is somewhat messy. Improve your variable naming and follow the Java-conventions. Comment less. Try to make your code so easy to read, that commenting feels useless, or better even, a hindrance for reading.
Code Snippets
//Include this class in the EvilMario game packageint x, dx, y, nx, nx2;
Graphics g;
Font fnt0, fnt1, fnt2;fnt0 --> arialLarge
fnt1 --> arialMedium
fnt2 --> arialSmall
g --> graphicsDevice
dx --> deltaX / xChange
nx --> newX (?)
nx2 --> secondNewX(?)Context
StackExchange Code Review Q#51118, answer score: 8
Revisions (0)
No revisions yet.