Jesse's Notes

Twelve Ways to Make Code Suck Less by Venkat Subramaniam

3 min read

Publishing/Release Date: November 10, 2016 Watched/Read: January 13, 2021 Link: https://www.youtube.com/watch?v=nVZE53IYi4w

  1. Schedule Time To Lower Technical Debt

    • Do we actually know what our technical debt is?

    • Slack time is time in your schedule that is not booked out. It is time to take a breather, time to consider the work we’ve done and improvements we can make.

  2. Favour High Cohesion

    • Think about frequency of change
      • Things that change with similar frequency, and for similar reasons, should be grouped closely together. Things that do not, should not.
    • High cohesion == low cyclomatic complexity

  3. Favour Loose Coupling

    • Tight coupling makes code:
      • hard to extend
      • hard to test
    • Eliminate coupling where possible

  4. Program With Intention

    • Kent Beck’s Rule for Simple Design
      • Passes the tests
      • Reveals intention
        • Code should be expressive, the more it reads like plain english, the better
      • No duplication
      • Fewest elements
        • Apply a certain minimalism in your writing, less (or no) code is significantly easier to maintain than more code.
    • Write a test before you write any code (TDD)

  5. Avoid Primitive Obsession

    • Imperative code is packed with accidental complexity
    • Prefer functional/declarative programming

  6. Prefer Clear Code Over Clever Code

  7. Apply Zinsser’s Principle On Writing

    • Simplicity
      • Reduce moving parts and mutability
    • Clarity
      • A lack of cohesion
      • Long methods
      • Poor code flow
      • … all contribute to a lack of clarity
    • Brevity
      • Shorter methods and classes are better
    • Humanity

  8. Comment Why, not What

    • Don’t comment to cover up bad code
    • Write expressive, self-documenting code
    • Good code is like a good joke
      • Writing comments is like explaining a joke

  9. Avoid Long Methods — Apply SLAP (Single Level of Abstraction Principle)

    • How long is long?
      • Turns out long is not about length of code, but levels of abstraction
      • Consider horizontal width, and levels of indentation
      • If you create new internal scopes inside a method, consider putting the body of the scope into a new method

  10. Give Good Meaningful Names

    • Variable names represent abstractions
    • If we can’t name a variable or function appropriately:
      • it may be a sign we’ve not yet understood its true purpose
      • in the case of a function, it may also be a sign that it’s doing too much

  11. Do Tactical Code Reviews

  12. Reduce State and State Mutation

    • Create state that serves the purpose, not self-serving state
    • Defer creation of state variables until they are absolutely necessary

Graph View