List of weak/unclear variable names to improve (some may need discussion)

[knod]

Include the variable name and the file path in which it appears. You can also add notes explaining yourself. Feel free to add them below or in new comments! Please don't get rid of or change something that someone else put down, though you can certainly add to the conversation surrounding it.

• [ ] 1. activeID GraphTimeButtons.js
• [ ] 2. client Everywhere. There are two clients. One for a client's account and one for the client data. Even without that, I'm not sure client is a great name for that data as it grows. The latter is complicated by the fact that it has the current and future props. Options: 1. account or accountData for... account data. 2. answers for form data. Then it can be all form data, not just client data. E.g. whether the client wants to fill in extra expense amounts. Is that something we want? current and future don't really fit into that model. 3. responses (similar, though with problems) 4. benefitData or dataForBenefits 😕 5. household for client data, since it really is the household we're collecting info about. This may change if we start to calculate individual benefits, such as with MassHealth. We'd have to talk to SMEs about that.
• [ ] 3. predictions Predictions.js and it's associated stuff. Not sure about this. We may need to keep it as it is since it indicates the future. It's partly a 'plain language' thing. Maybe report would work, but it's not as specific.
• [ ] 4. timeClient or whatever it is. I have to go. I'll find it later.

This may not be the best format for doing this. What would be better? Something with a reddit-like commenting system? We can discuss.

[knod]

• [ ] 5. income - often actually should be earnings

or earned

[dylanesque]

I combed through the files in the utils folder today. Most of it looks good or was touched upon in Michelle's comments above. One thing did stick out to me, though:

[] clientPartial from getSideEffects.js is pretty confusing.

[knod]

Great find! That's actually another attempt at timeClient or whatever it is.

[knod]

This looks like a duplicate, but it's not quite:

• [ ] 7. client

In my opinion client is very confusing. It sounds like it would have earned, hasSNAP, etc. straight in it, but it's actually current data and future data and those have that info in them. Can we find a better way to express these? Should it be split into separate variables?

Also, see #952.

[knod]

• [ ] 8. activeBenefits (and benefits in some places) - They include income, so a better name might be resources

[knod]

• [ ] 9. income is sometimes used when we mean earned income or pay

[knod]

From #968 (https://github.com/codeforboston/cliff-effects/pull/968#pullrequestreview-171856875):

• [ ] .interval to idSuffix or something

[knod]

• [ ] toFancyMoneyStr really isn't descriptive. It turns a number into a currency string, though right now it only makes US dollars. Not sure how to dance with that one.

[knod]

• [ ] toMoneyStr also isn't descriptive. I'm not sure what else to call it. It takes a number, adds to decimal points if needed, otherwise rounds a number to the first two decimal points, then returns a string of that. It's basically just a wrapper for .toFixed(2), but means we don't have to remember that functionality everywhere.