Project Review Error 404
Group
MysteryCrew
Ratings
-
Creativity: 4
It is quite creative. Yes, there are a few similar projects on the web with other technologies, but it still isn't a project that someone would expect.
-
Difficulty: 4
This project requires a lot of know how to implement. A lot of the programming Techniques used are not something you learn to use in a few minutes copying from youtube, like Resource Sharing, Asynchronous programming. etc. It also has a client/server communication which has it's own share of advantages and disadvantages. It's a pretty understandable way to communicate via client-server (using RMI in this case which needs even more things somebody needs to learn before implementing this project).
-
Positive aspects:
- It's a fun project to use. Web Apps like scribble, gartic phone etc are pretty famouse and pretty fun. This even has an advantage that it doesn't have ads, so it should be pretty fun to use as well.
- Clear Separation of Server/client
- Not rewriting multiple classes like the User-Class
- Documentation with JavaDoc about everywhere
- Separated connection logic from gui
-
Negative aspects:
-
JavaFX component initialisations in a few classes take about half the space of the entire class (repeating the same few lines of code quite often).
For example in ClientPaneStartFX:
btnColorRed.getStyleClass().add("btn-Red"); btnColorRed.setOnAction(this::processColorChange); btnColorRed.setVisible(false);
This 3 lines of code get repeated for evey single button, it could as well get done by a factory method or a builder (A factory method could get the style-class as a parameter since it's the only thing that changes).
-
Most exceptions just print the stack trace, which is great while developing, but in a packaged application with a GUI kind of useless, it might as well just be empty, most of the time you run a packaged application you don't run it from a command line, but just double click it (at least most normal users would), this means even if there is an output the user couldn't see it anywhays. Further more for a user having a non displayed error means he get's anoyed because he thinks the application doesn't run properly.
-
-
Programming Techniques
-
Interfaces: 5
2 Interfaces are used as stub, 1 is used for some syntactic sugar (to avoid try catch)
-
Generics: 5
Used with generally good reasons, on the throwingConsumer the Exception type isn't neccessarly important since it's called only once and with exception as a prameter, but it is pretty good to expand on
-
Exception handling: 3
Most exceptions just print the stackTrace, even if they could be intresting to maybe output the error in detail instead of the stack trace or act on them instead of just printing the stack trace.
-
Custom Exceptions: 4 The only reason both custom exceptions were created is to have a static message and have a different class. This could as well be done with a default exception passing a message in the constructor. This would have avoided the creation of 2 exceptions. There also already is a connectException which get's catched once with a few other connections to throw the ConnectionProblemException. This isn't neccessarly a bad idea bundling all under one name, but there is no real reason to do this since there already is a exception with a fitting name that works like the default exception. This is probably a individual optinion if a custom exception should be created or a already existing one should be used.
-
Method overriding: 5
There are plenty inherited methods being overridden to suit the functionality of the class.
-
Lambdas: 5
Lambdas are used pretty often wherever they can be used and the Lambda is used only in that case. Button click handling in the Client for example isn't handled in a lamda since a few buttons can use the same function.
-
File I/O: 5
Not really used much, a few file get loaded from memory, that's about everything file I/O happening in the application
-
Resource sharing: 5
The gamestate gets shared between multiple threads.
-
Streams: 5
They get used for example with collections on the server to pick the winner.
-
Asynchronous programming: 5
-
Collections: 5
Used in nearly every class, also makes sense since they are more comfortable and less verbose (comparing for example array and list).
-
-
.gitignore: 3
All 4 gitignores are the same (excluding the shard/gitignore which doesn't have the *.iml). One gitignore would be more than enaugh
-
README.md: 5
It contains everything it should and is nicely formatted and organized
-
Maven
- compiling: 2
- clean: 2
- run following README.MD: 1
- (on mac mvnw.cwd doesn't work, just using normal mvn)
- mvn plugin configuration: 2
- adopting mvn standard directory layout: 1
- yes, but in 3 subfolders of the project 3 times
-
Testing
- All tests passing: 2
- Coverage: 3
- There are no tests on the server (client is mostly only UI)
- efficiency of tests: 4
- Checks only point system
- understandablity: 5
- It's the test-name and their display name are nearly a full english sentence explaining what they do.
-
Documentation
- Documentation quality: 4
- The only methods that don't have JavaDoc are well-known methods, like start for a JavaFX application or self explanatory methods like startGameOverPane(...)
- Quite explicid documentation, could be positive, could be negative, depends on who get's asked. (very good documentation coverege that explains every detail)
/** * Getter used to retrieve the state of the lock (ie 0 or 1) for * the timer when all the user leave the game * session before the game is over. By setting it to 1 * we make sure that if joins a new user in the same game session * it will not call again the setTimerGame() method on top of the * already existing one. * * @return (Integer) state of the lock 1 or 0 */ public int getLocked() {return locked;}
- usefulness: 5
- generate docs: 0
- inline comments: 0-3?
- There aren't any
- Documentation quality: 4
-
Code quality:
- Code Style: 2
- code duplication: 2
- understandability: 2
- exessive inefficiency: 3?
- Doesn't neccessarly look inefficient
- accidental crashes: 3