Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Herreray code review two #10

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Conversation

Yep-Was-Taken
Copy link
Collaborator

  • Analysis of the program.
    I would say that the project has a pretty fleshed out application under development. I have seen good progress and merges since the last time I checked in code review one.

  • Was the program available in UC Github on time?
    I was able to access and raise this pull request before the deadline of the assignment so that I could submit on time.

  • Is the program easy for you, as an outsider, to understand?
    I suggested some changes that would lead to better outsider understanding - these also have an affect working towards lessening the technical debt in the project.

  • Does the program compile?
    Yes the program has compiled some of the tests that I did some small work in for terminal based output testing.

This merge request contains the three commits made to the project.

  1. I learned about the best practices involved in the source file creation for my commit: 5b7cef4. I made some changes in the ordering so that the variables are defined in the order of relevance followed by the constructors for visibility.
  2. In the second commit: 0e9d06d , I removed a method working towards the idea of cleaner code that would hope to reduce future struggle.
  3. I improved a use of JavaDoc in commit: fa920eb. This was explained in the java documentation examples on tutorialspoint, but I tagged the parameter expected for the method and the return is tagged as the ResponseEntity.

Looking at section 5.3 of baeldung's clean code they show an example that shows a well-formed source file as an example. This is also explained further in rhamedy's summary of best practices where it is shown with in line code comments the order of what should be expected in a code source file for readability. For these reasons I have restructured the file to have the private variables declared in order of visibility, followed by the base constructor and overloaded in sequential order, and at the bottom with the methods, getters, and setters needed for the project.
Sources:
https://rhamedy.medium.com/a-short-summary-of-java-coding-best-practices-31283d0167d3
https://www.baeldung.com/java-clean-code
This method removed seemed to have an unused end goal. This was removed on the basis of unfocused code as described in the Characteristics of Clean Code described in baeldung. The result returns a null value and if it was used later in development it could serve potential unhandled nulls which would be harder to trace back to this unlogged null. With the code being unused and not serving current function it would be my recommendation to remove the method.
Source:
https://www.baeldung.com/java-clean-code
I have added changes after reviewing the examples of best practices for JavaDoc in code documentation tags for your methods. This could be used as a starting point towards higher code coverage using java doc to explain the parameters and the returns of your methods as this source suggests.
Source:
https://www.tutorialspoint.com/java/java_documentation.htm
Comment on lines 14 to 16
public CartOrder(Food food, int foodQuantity) {
this.food = food;
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is foodQuantity in the signature, but not used in the method?

Comment on lines +18 to +20
public CartOrder(Food food){
this.food = food;
this.foodQuantity = 1;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And here, foodQuantity not in signature, but is used in method?

@discospiff
Copy link

Without cited sources, I'm not entirely clear if this branch reduces technical debt in a meaningful way. I'll leave the merge decision up to the team.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants