Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
round before calculating exponent in number_to_human_converter #26628
Introduced in: 597a927
Unfortunately the code to round in
I am fairly new to the Rails codebase, so I'm unsure of where to put the helper class. Should it go in its own file? Should it be a module?
There is also the messy fact that
Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @eileencodes (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
This repository is being automatically checked for code quality issues using Code Climate. You can see results for this analysis in the PR status below. Newly introduced issues should be fixed before a Pull Request is considered ready to review.
Please see the contribution instructions for more information.
referenced this pull request
Sep 26, 2016
In my opinion, since
RoundedHelper is being used by other classes than
NumberToRoundedConverter, it should be in its own file (activesupport/lib/active_support/number_helper/rounding_helper.rb). Probably it should be autoloaded from activesupport/lib/active_support/number_helper.rb like the other number converter files are.
I’m thinking, perhaps this PR should be 2 commits: 1) extracting
RoundedHelper, and 2) fixing the bug in
In the Rails codebase, the convention is to indent all code following the
private keyword with 2 extra spaces, and to have a whitespace inside
} in hashes – which is why the build fails ;-)
The new review system does make it easier to see what's changed. For larger PR's (big features or yak shaves) it makes more sense to add individual commits.
But I'm assigned this PR and I almost never look at individual commits and usually look at the PR as a whole so I don't mind if you add more commits.
@bquorning Thanks for the input, I definitely see what you mean about the initializer. I restructured the class a bit, removing the
Out of the 3 PR's fixing the mentioned issue this one seems to best address concerns of "what are the edge cases we're not thinking of beyond the one reported issue".
I have a few style changes I'd like to see but before I ask you to do more work @mjhoy I want to see what @matthewd thinks about the implementation since he disagreed with the original. The original issue is also a blocker for 5.0.1. Let me know what you think @matthewd.