codeforboston / codeforboston/cliff-effects
List of weak/unclear variable names to improve (some may need discussion)
- Dominant language
- JavaScript
- Stars
- 30
- Forks
- 62
- PR merge metrics
- No merged PRs in 30d
Description
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 `client`s. 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.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.