Project Review
Project Review
General
-
G1: How creative is the project? (
0
: I've seen this on Youtube,1
: not creative2
: average,3
: creative,4
: very creative,5
: wow!)- Answer: I would rate the creativity with 1.
-
Justification:
There are certainly similar projects on Youtube, and the internet in general, but the authors tried to give it a bit of an individual theme.
-
G2: How difficult was it to implement the project? (
0
: no challenge,1
: very easy,2
: easy,3
: fair,4
: complex,5
: insane)- Answer: It depends on the authors previous knowledge but I would say around 1-2.
- Justification: There are certainly some things that have to be learned in order to build this project. However, there can be found respective tutorials and example project which makes the learning process quite easy I would say.
-
G3: List 3 positive aspects of the project. Motivate your selection.
- 1. It works as expected after reading the README file.
- 2. It has a little bit of an individual theme as the ball has the shape of a Pokèball and a list of Pokèmon is generated.
- 3. The controls are simple and intuitive.
-
G4: List 3 negative aspects of the project. Motivate your selection.
- 1. I guess the implementation difficulty is a little to easy for the scope of the programming project course.
- 2. The pop up windows that appear after the game is finished are overlapping (just an aesthetics issue).
- 3. Most comments are in the code and there are no javadoc comments. That makes it a bit more difficult to understand the inner workings of the java classes.
Programming techniques
- PT1: Evaluate how well 5 programming techniques we learned throughout the course were adopted in the project. Assign a mark from
0
to5
to each technique, where0
means completely incorrect usage and5
means perfect usage.-
1. <Lambdas>
- Answer: 4
- Justification: Used correctly but applied very sparingly.
-
2. <Method overloading>
- Answer: 2
- Justification: One usage, which does not seem to be necessary.
-
3. <Method overriding>
- Answer: 4
- Justification: The methods were implemented correctly. The Override tag is missing.
-
4. <File I0>
- Answer: 1
- Justification: Strings are written to the txt file. However, the name of the used method getRandomItem is not reflecting its usage. Furthermore the textfile is overwritten 10 times with the same Strings which does not seem necessary.
-
5. <Exception handling>
- Answer: 3
- Justification: Basic but correct use of exception handling in one place. There would have been the opportunity for a more sophisticated use.
-
1. <Lambdas>
Git repository
-
GR 1: How appropriate is the
.gitignore
file of the project? (0
: missing,1
: very bad,2
: bad3
: average,4
: good,5
: very good)- Answer: 3
- Justification: There are some unnecessary parts of the .gitignore file and there is a commited target folder containing compiled files.
-
GR 2: How appropriate is the
README.md
file of the project? (0
: missing,1
: very bad,2
: bad3
: average,4
: good,5
: very good)- Answer: 4
- Justification: The README could be a little bit more elaborate. However, it nicely explains how to install and use the project. The necessary information is there and it is written in a clear way.
Maven
-
M1: Can you compile the project via Maven? (
0
: no,1
: yes, but...,2
: yes)- Answer: 2
- Justification: Works fine.
-
M2: Can you clean the project via Maven? (
0
: no,1
: yes, but...,2
: yes)- Answer: 2
- Justification: Works fine.
-
M3: Can you run the project via Maven? Check
README.md
on how to run the project. (0
: no,1
: yes, but...,2
: yes)- Answer: 2
- Justification: Works fine.
-
M4: Are the project's dependencies appropriately configured in
pom.xml
? (0
: no,1
: some,2
: yes)- Answer: 2
- Justification: They are.
-
M5: Are all Maven plugins appropriately configured in
pom.xml
? (0
: no,1
: some,2
: yes)- Answer: 1
- Justification: The 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing.
-
M6: Does the project adopt Maven's standard directory layout? (
0
: no,1
: yes, but...,2
: yes)- Answer: 2
- Justification: It does.
Testing
-
T1: Are all tests passing? Run
mvn test
. (0
: no,1
: yes, but...,2
: yes)- Answer: 1
- Justification: There are no tests that could fail.
-
T2: How well do the tests cover the code? (
0
: no tests,1
: no important method,2
: some important methods,3
: most important methods,4
: all important methods,5
: 100% test coverage)- Answer: 0-1
- Justification: There is one test method which creates a textfile but does not test anything.
-
T3: Do the tests actually verify the expected behavior of the program? (
0
: no tests,1
: useless tests,2
: most don't,3
: some do, some don't,4
: most do,5
: awesome tests)- Answer: 1
- Justification: The tests do not verify any behavior.
-
T4: How well can you understand what the tests are supposed to verify? (
0
: no tests,1
: what is going on?,2
: most are not understandable,3
: some are understandable, some aren't,4
: most are understandable,5
: all test are understandable)- Answer: 1
- Justification: It is understandable what the method does but it is not a real test method.
Documentation
-
D1: How understandable is the Javadoc written for classes, fields and methods of the program? (
0
: no documentation,1
: very poor,2
: poor,3
: average,4
: good,5
: awesome)- Answer: 0
- Justification: There are only some dangling javadoc comments which should better be regular line comments.
-
D2: How useful is the Javadoc written for classes, fields and methods of the program? (
0
: no documentation,1
: irrelevant,2
: little utility,3
: average,4
: useful,5
: very useful)- Answer: 0
- Justification:
-
D3: Can you generate documentation files for this project? Run
mvn javadoc:javadoc
. (0
: no,1
: yes, but...,2
: yes)- Answer: 1
- Justification: The command can be run but it is all automatically generated documentation.
-
D4: How adequate are the non-javadoc comments written throughout the code? (
0
: mostly inadequate,1
: average,2
: mostly adequate,3
: awesome)- Answer: 2
- Justification: The comments are mostly helpful even though some classes have very few and some to many comments.
Code quality
-
Q1: Is the code style adopted throughout the project consistent? Consider how whitespace is represented (spaces or tabs), tab size, naming conventions for classes, methods and variables, indentation, braces usage, line width. See Google Java Style Guide as an example of code style guidelines. (
0
: no,1
: yes, but...,2
: yes)- Answer: 1
- Justification: There are very long lines which makes the code hard to read at some places.
-
Q2: How would you rate the project in terms of code duplication? (
0
: a lot of duplication,1
: some duplication,2
: barely any duplication,3
: no code duplication / only justifiable duplication)- Answer: 2
- Justification: Some parts of the code could be more concise but there are not a lot of duplications.
-
Q3: How easy it is to understand how the program works by looking at the source code? (
0
: mostly hard to understand,1
: some fragments are hard to follow,2
: not hard, but not easy,3
: easy to understand)- Answer: 2
- Justification: Overall its core functionality is easy to understand but the naming of some methods and variables could be improved. Furthermore it is unclear what the Pokemon class is doing.
-
Q4: Is any section of the program excessively inefficient?
- Answer: I would say yes but it is not affecting the programs overall performance.
- Justification: the pokemon.txt file is overwritten several times with the same String data.
-
Q5: Does the program crash unexpectedly (e.g. by an uncaught exception)? (
0
: all the time,1
: rarely,2
: it happened once,3
: never)- Answer: 3
- Justification: I could not find a way to make the program crash.