Refactoring with Lombok #57
Conversation
src/main/java/org/heigit/ohsome/ohsomeapi/inputprocessing/InputProcessor.java
Show resolved
Hide resolved
...rg/heigit/ohsome/ohsomeapi/output/dataaggregationresponse/groupbyresponse/GroupByObject.java
Outdated
Show resolved
Hide resolved
...a/org/heigit/ohsome/ohsomeapi/output/dataaggregationresponse/DefaultAggregationResponse.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
I found some formatting/checkstyle issues.
regarding the main "content" of the PR, I'm missing a bit the rationale behind these changes. I see the amount of "boring" code like getter/setters is reduced. But it comes (at least in my IDE IntelliJ) at the cost that helpful stuff like code autocompletion doesn't work anymore. Or is there a trick to get this integrated into an IDE which I don't see right now, e.g., does one need to install a plugin or something?
//edit: I tried the instructions from https://www.baeldung.com/lombok-ide, but didn't have much luck. 😞
//edit2: ok, after a second try it worked (I must have misclicked something the first time). anyway, this really needs to be documented somewhere (readme, contrib. guide, …) IMO.
src/main/java/org/heigit/ohsome/ohsomeapi/executor/ExecutionUtils.java
Outdated
Show resolved
Hide resolved
| && "remainder".equalsIgnoreCase(jsonNode.get("groupByObject").get(1).asText())) | ||
| .findFirst().get().get("result").get(0).get("value").asInt(), 0); | ||
| assertEquals(43, | ||
| StreamSupport |
There was a problem hiding this comment.
why was the code formatting changed here?
There was a problem hiding this comment.
I have no answer for that, it is automatically formatted. I'm not using specific format settings which regard this issue.
There was a problem hiding this comment.
ok, I see. If you ask me, this is not a good situation to use automatic code formatting, for multiple reasons:
- First, the code was already correctly formatted, so why change it?
- Since we're not all using the same IDEs, if another person uses a different auto code formatter, the same line would potentially be changed again. This could result in an "edit war" of the auto formatters.
- Such changes make it hard to read and review a pull request, because more lines are touched and it is sometimes hard to see whether something really changed or if it was "just" the reordering of a few newlines and whitespaces.
- Most importantly, any such line which is touched without a reason can lead to unnecessary merge conflicts with other branches. This can cause lots of manual work down the line.
You might choose to use an auto-formatter during your own development however you like, of course. But if you do, please make sure not to commit unnecessary changes which were just introduced automatically. 🙏 git add -p is your friend.
There was a problem hiding this comment.
I also ran into that issue in the past (and sometimes sitll today), which can indeed be a bit annoying and missleading.
What I try to remember myself always now is just marking the specific code lines, or method, that I've added/edited and then apply the auto formatting on that, instead of the whole class.
Sometimes it really changes something on a completely other part of the code, which also fits to the coding guidelines, but is just another way of ordering the lines..
I can write something on confluence about it or elsewhere. Where is it better? @FabiKo117 @tyrasd |
|
IMHO, for now https://github.com/GIScience/ohsome-api#getting-started seems like the best place to start. Or alternatively start a github wiki page. |
making construct private deleting construct annotation
fitting methods fitting junit tests
not prioritizing domain package import formatting pom.xml
to use 2 spaces instead of one tab
to be in alphabetical order
|
360508a changed the JSON output of all |
tyrasd
added
the
code quality
For further discussions: #50