Skip to content

Conversation

@angethuy
Copy link

@angethuy angethuy commented Feb 6, 2020

Assignment Submission: Calculator

Congratulations! You're submitting your assignment. Please reflect on the assignment with these questions:

Reflection

Question Answer
What went well in your code style, such as indentation, spacing, variable names, readability, etc.? What was lacking? My code is not a fully functional calculator yet, but I think so far my indentation is readable and the variable names are informative.
How did your code keep track of user input? It uses input to populate a hash containing operator and 2 numbers.
How did your code determine what operation to perform? Oh my gosh ok so I fell down a really deep rabbit hole when I discovered that when you're writing case statements in ruby, you can pass arrays as variables to each "when" by using * (SPLAT!) on arrays. So my plan was to determine which operation to perform by taking the user input and running it through a case statement that's written with a bunch of nifty splatted arrays. Mostly because I thought it might be cool to only write each dictionary of operations once and reuse it as needed.
What opportunities exist to create small methods for this project? Prompting and processing user input, validating input, performing the operation are all distinct actions that can be smaller methods.
In the next project, what would you change about your process? What would you keep doing? I think I need to pull the reins back on my wild "oh this ruby trick/syntax is really cool" ponies and corral them until I get an maybe-less-elegant-but-way-more-functional solution in place. Then the ponies can run wild during refactoring and DRYing.

@CheezItMan
Copy link

CheezItMan commented Feb 6, 2020

Calculator

Major Learning Goals/Code Review

Criteria yes/no, and optionally any details/lines of code to reference
Correctly uses conditionals (if/else/elsif) 👍
Correctly uses loops (while/until) 👍
Correctly uses gets.chomp 👍
Correctly uses variables 👍
Correctly creates and uses custom methods 👍 Do see my one small note on your method.

Functional Requirements

Functional Requirement yes/no
User can input two numbers and an operator and perform addition 👍
User can input in two numbers and an operator and can perform subtraction 👍
User gets feedback from the CLI when attempting to divide by zero, and the program does not give an error ⚠️ It reports infinity for division by zero and crashes on modulus with 0.

Overall Feedback

Overall Feedback Criteria yes/no
Green (Meets/Exceeds Standards) 3+ in Code Review && 2+ in Functional Requirements 👍

Code Style Bonus Awards

Was the code particularly impressive in code style for any of these reasons (or more...?)

Quality Yes?
Perfect Indentation 👍 Nice indentation and meaningful variable names.
Elegant/Clever 👍 Good use of a hash and a case statement.
Descriptive/Readable 👍
Concise 👍
Logical/Organized 👍

Summary

Apologies for the confusion, when you submit a pull request, we're going to evaluate it and provide feedback, so I suggest not making a PR until you are ready to submit. There will be projects where it's not completely working when you submit and that's ok, you can get feedback on what you have.

@angethuy
Copy link
Author

angethuy commented Feb 6, 2020

Assignment Submission: Calculator

Note: Revised reflection to accompany my code revision!

Reflection

Question Answer
What went well in your code style, such as indentation, spacing, variable names, readability, etc.? What was lacking? I think I indented well and the code is blocked/spaced in a reasonable manner. I still struggle with choosing meaningful iterator variable names.
How did your code keep track of user input? It uses input to populate a hash containing operator and 2 numbers.
How did your code determine what operation to perform? It uses a case statement (with SPLATTED ARRAYS hooray) to compare user inputted operator against a dictionary of known operators, then evaluates the math associated with the operator.
What opportunities exist to create small methods for this project? Prompting and processing user input, validating input, performing the operation are all distinct actions that can be smaller methods.
In the next project, what would you change about your process? What would you keep doing? I think I need to pull the reins back on my wild "oh this ruby trick/syntax is really cool" ponies and corral them until I get an maybe-less-elegant-but-way-more-functional solution in place. Then the ponies can run wild during refactoring and DRYing. I also ran into trouble when I tried to validate AND do-cool-evaluative-stuff with user input at the same time. I think for future validation problems, I'll focus on performing each task separately first.

Fixed some wonky .to_s/.to_f/.to_i bugs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants