-
Notifications
You must be signed in to change notification settings - Fork 9
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
API specs #13
Comments
+1 |
yes |
I actually prefer percents represented as decimals - I know integers are more readable, and possibly make more immediate sense to people, but mathematically, they aren't proper numeric representations, they would always have to be divided by 100 to do any math, and then multiplied by 100 when returned, and that just seems like something that is more appropriate to the front-end. For instance, cfpb/student-debt-calc takes a lot of "rates" (which would textually be written as percentages, like "7.55%") but it takes them in as decimals (like The front-end of cfpb/college-costs takes user input of rates in the "percentage" format ("7.55%") and divides them by 100 to pass them to decimals to the calculator package. It takes what the calculator returns and multiples it by 100 to display the output. That makes more sense to me than the package taking in numbers it doesn't really want. Since we're talking about packages doing math, not front-ends displaying values, I think decimals just make more sense. |
These two rules I totally 👍 🎆 😋 |
Fine by me. |
We should standardize our function signatures. Right now we're all over the place. Here are some rules I just made up. Feel free to add your own.
cashFlow({income: 100000, expenses: 50000})
and notcashFlow(100000, 50000)
20
and not.2
interest
returns an object with both the interest amount, and the total amount. The user could easily add their principal to the interest to get the total themselves, but it's nice to do it for them.The text was updated successfully, but these errors were encountered: