programming
- Avoid adding comments to code; they usually clutter the code and get stale easily.
- Only use them to explain difficult to read behavior and other out-of-band info.
- Actively remove stale comments and docstrings that don't add value.
- Use intention-revealing names instead and maintain a consistent vocabulary across the codebase.
- Functions
- Prefer stateless/pure functions, as they're easier to test and reason about.
- Separate I/O operations from business logic (Functional Core, Imperative Shell pattern).
- Googleblog source
- Extract decision logic into pure functions.
- Keep side effects (database calls, API requests, file I/O) in the outer shell layer.
- This makes core logic testable without mocking and reusable across features.
- Aim for one level of abstraction per function.
- Try to keep them short.
- If a function needs many arguments, consider using an object or splitting it into multiple functions.
- Run code that you write unless explicitly told not to.
- It is imperative that you verify the code you write works as intended.
- Avoid mutable global state; it leads to unintended side effects.
- Prefer reusing and extending things.
- e.g.: if fixtures exist, use them or generalize them.
- But beware: existing code might be broken; build on top of it, but always test it.
- Avoid unnecessary breaklines in the code; they make the file needlessly longer.
- Keep related code vertically dense.
- Declare variables close to usage.
- Place functions that are dependent on one another close together to make it easier to follow the flow of logic.
- Place functions in a downward direction, with higher-level functions appearing before lower-level ones.
- Keep related code vertically dense.
- When writing validation logic, prefer early returns on errors.