-
Notifications
You must be signed in to change notification settings - Fork 21
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
Comments
Refactoring should be done in the refactor branch: https://github.com/SciRuby/rubex/tree/refactor |
Do we have a Roadmap or Milestones planned for refactoring? |
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. |
I've updated with a rough list. |
Gitter or slack would be best. |
So its mainly done that way because all the classes under say 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. |
Yup. Check this |
OK. I'm sold. I'm updating the above list to reflect this change. |
I can start working on separating the classes. If no-one else has already taken it up. |
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. |
MethodCall#analyse_statement: 0779f56 |
CommandCall#generate_evaluation_code : 012963f |
Name#analyse_statement: a31144b |
ElementRef: 583d859 |
@shaunakpp any progress on your end? |
I'll attempt it this weekend. Been a bit busy with work.
…Sent from my Nokia 3310
________________________________
From: Sameer Deshmukh <[email protected]>
Sent: Thursday, January 18, 2018 10:10:45 AM
To: SciRuby/rubex
Cc: Shaunak Pagnis; Mention
Subject: Re: [SciRuby/rubex] Identify 'code smell' and refactor. (#35)
@shaunakpp<https://github.com/shaunakpp> any progress on your end?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#35 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADBfHrkBoHEgLVk1b5CyEg3lYbpM6sCPks5tLstNgaJpZM4RaaM5>.
|
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
Too long and does too many things.
analyse_statement
inExpression
classesThe
analyse_statement
method should only analyse statements and make sense of their typesand 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
classClass 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
andExpression::ArgList
. There should be only one class for dealing with argument lists.The text was updated successfully, but these errors were encountered: