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

API specs #13

Open
contolini opened this issue Nov 6, 2015 · 5 comments
Open

API specs #13

contolini opened this issue Nov 6, 2015 · 5 comments

Comments

@contolini
Copy link
Contributor

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.

  • Methods should receive a single object argument.
    • e.g. cashFlow({income: 100000, expenses: 50000}) and not cashFlow(100000, 50000)
  • Percent values should be represented as integers.
    • e.g. 20% is 20 and not .2
  • Output should be as verbose as possible
    • e.g. 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.
@ascott1
Copy link
Collaborator

ascott1 commented Nov 6, 2015

+1

@cfarm
Copy link
Contributor

cfarm commented Jan 5, 2016

yes

@mistergone
Copy link
Collaborator

Percent values should be represented as integers.

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 .0755). Setting aside entirely that "7.55%" can't technically be represented as an integer, I think it's less confusing to take as an input the mathematical value that the code is going to use anyway. I also think it's a little silly to take in a 20 when you know your code needs a .2 to actually do its work.

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.

@mistergone
Copy link
Collaborator

Methods should receive a single object argument.
Output should be as verbose as possible

These two rules I totally 👍 🎆 😋

@contolini
Copy link
Contributor Author

I think decimals just make more sense.

Fine by me.

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

4 participants