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.
• •When writing validation logic, prefer early returns on errors.