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

Identify 'code smell' and refactor. #35

Open
8 of 12 tasks
v0dro opened this issue Jan 11, 2018 · 16 comments
Open
8 of 12 tasks

Identify 'code smell' and refactor. #35

v0dro opened this issue Jan 11, 2018 · 16 comments

Comments

@v0dro
Copy link
Member

v0dro commented Jan 11, 2018

Rubex was written in a bit of hurry, so parts of the code base are quite messy. Identify these smelly parts and refactor them with better design. Refer to Martin Fowler's Refactoring Ruby book for reference. Here's a rough list based on basic parameters like a method/class doing too many things or being too long. Feel free to add your own.

  • Statement::Alias#analyse_statement.
    This method is using an if-else approach for detecting function pointers. Ideally we should use a new class for denoting function pointers for arguments (like this commit: ff00ff8)

  • Expression::MethodCall#analyse_statement

Method is too long and does too many things in 30 lines of code :O

  • Expression::Name#analyse_statement

Too long and does too many things.

  • analyse_statement in Expression classes

    The analyse_statement method should only analyse statements and make sense of their types
    and generate symbol table entries etc. Currently methods of this name exist in Expression
    classes as well. This should go so that there is a clear demarcation between statements and
    expressions. Don't just rechristen to analyse_expression. Let there be some value to it.

  • Separate classes into their own files as per ruby-style-guide.

  • Expression::CommandCall#generate_evaluation_code
    Method is too long and does too many things. Too many conditionals.

  • ElementRef#analyse_statement

  • ElementRef#generate_evaluation_code

  • Expression::StringLit class
    Class trying to be both a Ruby string and C string. Segregate.

  • Refactor temp allocation mechanism. Current mechanism requires too much work on part of programmer.

  • Refactor code generation. Current mechanism relies on the c_code construct which does not convey meaning properly and does too many things in one method in many cases.

  • Unify Statement::ArgumentList and Expression::ArgList. There should be only one class for dealing with argument lists.

@v0dro
Copy link
Member Author

v0dro commented Jan 11, 2018

Refactoring should be done in the refactor branch: https://github.com/SciRuby/rubex/tree/refactor

@shaunakpp
Copy link
Contributor

Do we have a Roadmap or Milestones planned for refactoring?
Also, what needs refactoring and what not can be subjective, so can we keep a dedicated channel for discussing this?

@v0dro
Copy link
Member Author

v0dro commented Jan 11, 2018

Works. How do you think a channel should be setup? Gitter or something?

I'm currently figuring out things to refactor myself. Will post my list in this thread now.

@v0dro
Copy link
Member Author

v0dro commented Jan 11, 2018

I've updated with a rough list.

@shaunakpp
Copy link
Contributor

Gitter or slack would be best.
Also, one thing I noticed was that files in lib/rubex/ast/ implement multiple classes in one single file. If we keep separate files for separate classes, it will help in maintaining the project and also reduce the overall code-churn. What do you think?

@v0dro
Copy link
Member Author

v0dro commented Jan 11, 2018

So its mainly done that way because all the classes under say expression.rb cater to only expressions, and most of these classes tend to be interdependent so it makes it easier to read and make edits between classes. Also, most of them are quite small too (average of 40 lines, max 100 lines) so I didn't think it would be best to split them into multiple files.

Is having a class per file a best practice, though?

I'll setup Gitter soon. I'll also open a #rubex channel on the sciruby slack.

@shaunakpp
Copy link
Contributor

shaunakpp commented Jan 11, 2018

Is having a class per file a best practice, though?

Yup. Check this
But if there are a lot of interdependent classes, we can keep references to files in comments, wherever required.

@v0dro
Copy link
Member Author

v0dro commented Jan 12, 2018

OK. I'm sold. I'm updating the above list to reflect this change.

@shaunakpp
Copy link
Contributor

I can start working on separating the classes. If no-one else has already taken it up.

@v0dro
Copy link
Member Author

v0dro commented Jan 12, 2018

Sure. Please commit your changes to the 'refactor' branch. And be sure to send regular PRs so that I can pull your latest changes. This approach is just easier than having to merge two conflicting branches into the master later.

@v0dro
Copy link
Member Author

v0dro commented Jan 13, 2018

MethodCall#analyse_statement: 0779f56

@v0dro
Copy link
Member Author

v0dro commented Jan 13, 2018

CommandCall#generate_evaluation_code : 012963f

@v0dro
Copy link
Member Author

v0dro commented Jan 14, 2018

Name#analyse_statement: a31144b

@v0dro
Copy link
Member Author

v0dro commented Jan 16, 2018

ElementRef: 583d859

@v0dro
Copy link
Member Author

v0dro commented Jan 18, 2018

@shaunakpp any progress on your end?

@shaunakpp
Copy link
Contributor

shaunakpp commented Jan 18, 2018 via email

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