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

Code Review #180

Closed
umutuz7 opened this issue Dec 13, 2015 · 1 comment
Closed

Code Review #180

umutuz7 opened this issue Dec 13, 2015 · 1 comment
Assignees

Comments

@umutuz7
Copy link
Contributor

umutuz7 commented Dec 13, 2015

Review the commit ad6207e by omer temel.

@umutuz7 umutuz7 self-assigned this Dec 13, 2015
@umutuz7
Copy link
Contributor Author

umutuz7 commented Dec 13, 2015

@omermtemel

You should commit your code when all parts of an entity is ready. I see you have two other commits about violation entity.. You should avoid this style as long as you don’t have a valid reason. I will try to include those two other commits in my review.

I believe your code is clear to understand but you didn’t write any comments. At least you must have documentation for the controller in order to let frontend and android teams to refer.

You should carefully read the requirements before you start implementig an entity as it is much harder to change it in the future. I see that modification date field is added later than your first commit.

You have no tests written for violation entity. You should complete your tests and commit them as soon as possible.

I checked your code with IntelliJ Code Analyzer. Here are some comments i want you to consider.
In entities/Violation.java, one of the constructors has an unused parameter, Boolean active. This is indeed replaced by closed field, you should remove it.

In dtos/ViolationDTO.java, there is an unused import import java.util.Date;. This is because date field once thought to be filled by the user, but then converted to automatically filled with creation date. So you can remove this import. The problem with the unused active parameter exist here also.

My conclusion about the code analysis is the following. The mistakes are really easy to detect with IntelliJ Code Analyzer. It also suggest solutions and apply the suggested solution (for example removing the acvitve parameter) by just one click.

@umutuz7 umutuz7 assigned omermtemel and unassigned umutuz7 Dec 13, 2015
@umutuz7 umutuz7 closed this as completed Jan 1, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants