Project peer review by Error404
Project: Linear Algebra Library
General
- G1: How creative is the project? (
0
: I've seen this on Youtube, 1
: not creative 2
: average, 3
: creative, 4
: very creative, 5
: wow!)
-
Answer: 3
-
Justification: There do already linear algebra libraries exist and Java already provides a Vector class in the java.util package, for example, but it does not provide that much methods as in this project.
- G2: How difficult was it to implement the project? (
0
: no challenge, 1
: very easy, 2
: easy, 3
: fair, 4
: complex, 5
: insane)
-
Answer: 3
-
Justification: Mathematical knowledge is required for most methods.
- G3: List 3 positive aspects of the project. Motivate your selection.
-
1. The code was split into several classes -> Easier to understand
-
2. Clear code structure within the classes
-
3. JavaDocs are very clear
- G4: List 3 negative aspects of the project. Motivate your selection.
-
1. For some complex methods line comments would help to understand.
- 2.
- 3.
Programming techniques
- PT1: Evaluate how well 5 programming techniques we learned throughout the course were adopted in the project. Assign a mark from
0
to 5
to each technique, where 0
means completely incorrect usage and 5
means perfect usage.
-
1. Custom Exceptions
-
Answer: 5
-
Justification: Created custom exceptions and used them adequately.
-
2. Abstract classes
-
Answer: 5
-
Justification: Used in class NTupel. Extended that class in IntTupel and FloatTupel -> used correctly
-
3. \Generics
-
Answer: 5
-
Justification: Used generics correctly in the classes MatrixOperations, NTupel, VectorOperations, BaseOperations, ...
-
4. Streams
-
Answer: 5
-
Justification: Used streams correctly. But they are sometimes hard to follow, especially in complex methods.
-
5. Lambdas
-
Answer: 5
-
Justification: Used labdas correctly. For lambdas which include only one line, he did not use { and } which makes the code clearer.
Git repository
- GR 1: How appropriate is the
.gitignore
file of the project? (0
: missing, 1
: very bad, 2
: bad 3
: average, 4
: good, 5
: very good)
-
Answer: 5
-
Justification: IntelliJ and Eclipse are considered. Maybe also add Visual Studio Code.
- GR 2: How appropriate is the
README.md
file of the project? (0
: missing, 1
: very bad, 2
: bad 3
: average, 4
: good, 5
: very good)
-
Answer: 5
-
Justification: Everything is present and clearly described
Maven
- M1: Can you compile the project via Maven? (
0
: no, 1
: yes, but..., 2
: yes)
-
Answer: 2
-
Justification: Maven compile works
- M2: Can you clean the project via Maven? (
0
: no, 1
: yes, but..., 2
: yes)
-
Answer: 2
-
Justification: Maven clean works
- 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: undefined
-
Justification: This is a library and not intended to run on its own
- M4: Are the project's dependencies appropriately configured in
pom.xml
? (0
: no, 1
: some, 2
: yes)
-
Answer: 2
-
Justification: All required dependencies are present
- M5: Are all Maven plugins appropriately configured in
pom.xml
? (0
: no, 1
: some, 2
: yes)
-
Answer: 2
-
Justification: All maven plugins configured
- M6: Does the project adopt Maven's standard directory layout? (
0
: no, 1
: yes, but..., 2
: yes)
-
Answer: 2
-
Justification: Project adopts Maven's standard directory layout
Testing
- T1: Are all tests passing? Run
mvn test
. (0
: no, 1
: yes, but..., 2
: yes)
-
Answer: 2
-
Justification: All tests are passing
- 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: 5
-
Justification: Every class is tested including edge cases
- 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: 5
-
Justification: All tests make sense and work
- 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: 5
-
Justification: All tests are explained with the @DisplayName annotation clearly
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: 5
-
Justification: Very clear and understandable. Added to class and method where appropriate.
- 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: 5
-
Justification: Some of them are not necessary. But all in all they help to understand the code better.
- D3: Can you generate documentation files for this project? Run
mvn javadoc:javadoc
. (0
: no, 1
: yes, but..., 2
: yes)
-
Answer: 2
-
Justification: Javadoc html files are created successfully
- 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: some comments are not really needed. Maybe some more comments on the more complex methods.
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: 2
-
Justification: The code style is consistent. Tabs are always 4 white spaces, the naming of variables and classes are according to the scheme varName, not var_name.
- 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: In IntTupel and FloatTupel which both extend NTupel, there is some duplication.
- 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: 3
-
Justification: Used line breaks to split a method internally to make it easier to follow.
- Q4: Is any section of the program excessively inefficient? (
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: Some complex mathematical methods can be hard to understand.
- 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: Does not crash at all.