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

General refactoring #76

Open
nickserv opened this issue Jan 6, 2014 · 4 comments
Open

General refactoring #76

nickserv opened this issue Jan 6, 2014 · 4 comments

Comments

@nickserv
Copy link
Collaborator

nickserv commented Jan 6, 2014

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

@technicalpickles
Copy link
Owner

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.

@nickserv
Copy link
Collaborator Author

nickserv commented Jan 9, 2014

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.

@technicalpickles
Copy link
Owner

Sounds fair, would be interesting to see those changes. When you submit a PR for those, could you include the rubocop before & after?

@nickserv
Copy link
Collaborator Author

... 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants