General refactoring
nickserv opened this issue · 4 comments
I have started work on some of this on my refactor branch several 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
- Make rubocop happy with our source code.
- Separate implementation and specs into more files.
- Reduce duplication.
- Make things more modular
- Use more libraries to avoid "reinventing the wheel".
- Move each group of commands into their own/class file. For example, symlink/unsymlink could be together. We could also have spec files separated into these command groups.
Thanks to @trobrock for some of these refactoring ideas.
Related issues
Make rubocop happy with our source code.
I'd be weary of aiming for this for it's own sake, having tried to placate static analyzers in the past :)
Use more libraries to avoid "reinventing the wheel".
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.
Make rubocop happy with our source code.
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 ClassLength and Eval that I have been ignoring for now, though.
Sounds fair, would be interesting to see those changes. When you submit a PR for those, could you include the rubocop before & after?
... 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.