- Readability is important for maintaining a good app. Make sure your code matches the standard for the project.
- Don't try to be clever. Writing code that other developers understand is more important than writing code that runs as fast as possible, or that is as short as possible.
- Never nest ternaries. Just don't. They're hard to read.
- Code should either work or not work. It should be clear when something is not working. There should be never be an in-between, intermediate half-working state. Eg if a build fails then it shouldn't be in a running-but-not-working state afterwards.
- Leave the code in a better state than it was when you found it. Refactor things that can be simplified, rename things that are badly named, add comments to explain what you've discovered, add tests for things that don't have tests.
- Commits, PRs, and documentation are searchable, so include terms that people might be searching for in your git messages.
- Don't assume that data is available. Always check.
- Properly handle cases where data is missing, or the wrong type, or outside of expected boundaries. Validate data that's being used.
- Network requests can be slow, or fail, or arrive out of order. UIs should handle waiting (show a spinner) and failure (show an error)
- Network requests should be done as early as possible, but not too early. Data should be requested as soon as the app is aware that the response will be needed, but no so early that the data might be unused.
- Don't request data that the user has already got. Cache things to save on network requests.
- Some apps need up-to-date data to function. Don't rely on cached data if it could cause an error.
- Consistency is important. Don't define a new style if you can reuse an existing one.
- Consider changes when you're defining things. How hard will it be to change something later? If it's likely to change then use a constant.
- Enable accessibility when you can. Add alt text, ARIA tags, and semantic markup.
- Try to give constructive feedback that people can build on; don't give an unjustified opinion.
- Point out mistakes and errors without criticism if possible. The goal is for the team to make a good app.
- Praise things that have been done well. Try to do this publicly where others can see it happening.
- Write documents that explain complex things. Don't try to explain complicated things in a comments or chat messages.
- Treat chat messages as if they're temporary.
- If something will be refered back to after a story is complete, put it in a document. Stories and chat are rarely looked at once something is marked as Done.