-
Notifications
You must be signed in to change notification settings - Fork 125
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
General refactoring #76
Comments
I'd be weary of aiming for this for it's own sake, having tried to placate static analyzers in the past :)
Depends on the wheel I think. If our usage is simple enough, it's usually easier to invent that wheel than coming up to speed with someone else's wheel. |
So far, I have most of this done. If you (@technicalpickles) don't like some of the rubocop-related refactoring I worked on, we could always revert part of it and ignore the relevant features in the rubocop config. I don't think the changes would hurt though. (By the way, some of my changes do require syntax features that are only in Ruby 1.9+.) There are some difficult-to-obey cops like |
Sounds fair, would be interesting to see those changes. When you submit a PR for those, could you include the rubocop before & after? |
Do you mean a log of rubocop's output before and after the refactor? Sure, but I'd have to temporarily remove the config file from my refactor branch because it silences some of the issues that haven't been fixed yet. I'll probably link you to a couple gists for rubocop's output once I send the PR. |
I have started work on some of this on
my refactor branchseveral of my branches. If you would like to work on the branch with me, let me know and I can accept PRs / add you as a collaborator.Ideas
Thanks to @trobrock for some of these refactoring ideas.
Related issues
The text was updated successfully, but these errors were encountered: