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: These games are not that rare, but the bang thing was new
G2: How difficult was it to implement the project? (0: no challenge, 1: very easy, 2: easy, 3: fair, 4: complex, 5: insane)
Answer: 4
Justification: It is an average project, but working alone is not easy
G3: List 3 positive aspects of the project. Motivate your selection.
1. It is an ambitious project - Even if the developers did not have much time to develop the project,
managed to create an interesting and complex program, different from common project ideas.
2. Faster coding - Creating a program with blocks instead of writing statements line by line is faster,
at least for the base of a simple program.
3. Export features - The built file in VCE can be exported, and the user can keep working on it outside this editor.
G4: List 3 negative aspects of the project. Motivate your selection.
1. The project does not run - It is not possible to run the project with maven commands or with the JAR file, we used IntelliJ to run it.
2. Many nodes, messy UI - If there are many nodes, the editor becomes difficult to handle as the nodes are not resizable, scrolling
on the screen is a bit slow, and the connections (white lines) might create a 'web'.
3. Not very intuitive UI and functionality - It is not that straightforward, someone who approaches VCE for the first time might get
lost if they do not carefully follow the guide.
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. Streams
Answer: 5
Justification: The use of streams is effective. They do their task and prevent the code from having unnecessary loops
2. Method overriding
Answer: 5
Justification: As this is a big project, it needs an organized and hierarchical structure. The method overriding is necessary as the project has different
libraries, numerous interfaces, and a pair of abstract classes. This programming technique is used as it should.
3. Interfaces
Answer: 5
Justification: The interfaces are extremely useful and effective here, as many nodes can implement different interfaces and inherit specific
methods and features.
4. Regular expressions
Answer: 4
Justification: They were effectively used mainly to check if the format of a class, method, or variable was ok. (e.g. The name of the class cannot star with a number).
However, they were a bit hard to understand without a comment explaining the pattern.
5. Generics
Answer: 5
Justification: The use of generics was a wise decision, especially to handle the different components in the Renderable and View interfaces.
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: The .idea is showed in the repository. The rest is good.
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: 4
Justification: It has the basic structure, and the additional 'HowToUseTheNodes.md' is useful, but there is no video.
Maven
M1: Can you compile the project via Maven? (0: no, 1: yes, but..., 2: yes)
Answer: 2
Justification: Yes
M2: Can you clean the project via Maven? (0: no, 1: yes, but..., 2: yes)
Answer: 2
Justification: Yes
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: 0
Justification: It is not possible to run it with commands, or the JAR file.
M4: Are the project's dependencies appropriately configured in pom.xml? (0: no, 1: some, 2: yes)
Answer: 2
Justification: Yes, they are well configured and structured
M5: Are all Maven plugins appropriately configured in pom.xml? (0: no, 1: some, 2: yes)
Answer: 2
Justification: They are well configured and structured
Justification: Mostly yes, but there is the doc folder in the project directory. Also, the 'resources' folder is inside the 'java' folder
Testing
T1: Are all tests passing? Run mvn test. (0: no, 1: yes, but..., 2: yes)
Answer: 1
Justification: All the tests run successfully. However, when the project is packaged with Maven, it says
that 3 tests passed (there should be 18), but if we run directly from the IDE all of them work.
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: 3
Justification: They cover only the basic parts of the project, like the I/O, and code comparison with maps, and the transpiler export.
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: 4
Justification: The tests written verify the basic functionality of the program.
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: 4
Justification: Most of them are understandable, they are well-structured and test the respective functionalities.
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: 4
Justification: Most of the documentation is useful to understand some parts of the code work. This was needed as the project is too big
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: 3
Justification: There are several fields, methods and classes that are not documented. Some descriptions of
parameters and the return objects are not there.
D3: Can you generate documentation files for this project? Run mvn javadoc:javadoc. (0: no, 1: yes, but..., 2: yes)
Answer: 1
Justification: It is generated successfully, but with errors because of missing description, parameters, and bad use of characters
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 were clear and useful, but there are some dangling TODOs.
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 is consistent and well-structured.
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: There is some code duplication in the JsonIterator class.
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: 1
Justification: The code is not easy to follow for us because it is big and complex, but running the program and being patient helps to understand it better.
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: We haven't found noticeable efficiency problems, but the code duplication.
Q5: Does the program crash unexpectedly (e.g. by an uncaught exception)? (0: all the time, 1: rarely, 2: it happened once, 3: never)