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

Fix various issues reported by SonarCloud reports #2229

Merged
merged 14 commits into from Mar 4, 2019
Merged

Fix various issues reported by SonarCloud reports #2229

merged 14 commits into from Mar 4, 2019

Conversation

} else {
return "null";
}
return "null";
Copy link
Member

Choose a reason for hiding this comment

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

The code block aims to illustrate what type to check when computing the example value.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@wing328 I don't get your point, the previous code block returns null in all cases. Can you please elaborate more?

Copy link
Member

Choose a reason for hiding this comment

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

My point is that for someone new to the code base, they may have no clue what type to check and what function to leverage (e.g. ModelUtils.isIneger) to check the type.

The code is put there for onboarding new users.

Copy link
Member

Choose a reason for hiding this comment

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

Maybe it can be reverted and a note can be added that the conditionals exist as examples for new contributors?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I would put the conditionals as comment to enlighten new contributors and just leave the code return null. I personally prefer to have cleaner code and cover the unusual case in a comment

Copy link
Member

Choose a reason for hiding this comment

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

I often agree with this approach. However, if any of the methods are renamed, comments are often missed and this can be confusing.

From another approach, new and existing contributors might not easily reason about what a single "null" result would mean here, while the explicit cases provide clear intention.

I think commenting on either way would be acceptable. We can always change later if people have questions.

} else {
return "null";
}
return "null";
Copy link
Member

Choose a reason for hiding this comment

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

@wing328
Copy link
Member

wing328 commented Mar 1, 2019

cc @OpenAPITools/generator-core-team as well

@wing328
Copy link
Member

wing328 commented Mar 1, 2019

For #788

@wing328
Copy link
Member

wing328 commented Mar 2, 2019

Minor suggestion: next time you may want to create a new branch for the change.

@wing328
Copy link
Member

wing328 commented Mar 3, 2019 via email

Copy link
Member

@wing328 wing328 left a comment

Choose a reason for hiding this comment

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

LGTM

@wing328 wing328 merged commit cc1fe6e into OpenAPITools:master Mar 4, 2019
@wing328 wing328 changed the title fix resources management Fix various issues reported by SonarCloud reports Mar 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants