programming.md

Programming

Uncle Bob - The only way to go fast is to go well! - https://www.youtube.com/watch?v=7EmboKQH8lM&list=PLmmYSbUCWJ4x1GO839azG_BBw8rkh-zOj&index=1

• Functions should be extremely small, like under 10 lines if possible

  • Continue extracting out functions until you can't reasonably extract any more
    • Code should read like prose
  • Group functions that modify the same variables into classes

• Functions should only have a few arguments, 3 or 4 at most

  • Avoid using booleans as function arguments. Instead, extract the boolean portion out into its own function
  • Functions that need more arguments should receive objects or data structures

• Functions that return values should not have side-effects

  • Only functions that return nothing should have side-effects

• Every line of a function should be at the same level of abstraction

• Comments are for when we can't express ourselves clearly enough in code

  • Use the names of functions and variables to explain code rather than comments

• Use longer variable names in larger scopes, shorter variable names in narrower scopes

• Function names are the opposite - SHORTER function names in wider scopes, LONGER function names in narrower scopes

• Rules of Test-driven Development

  1. You're not allowed to write any production code until you've first written a test that fails (the test fails because the production code doesn't exist)
  2. You're not allowed to write more of a test than what is sufficient for it to fail
  3. You're not allowed to write any more production code than what is sufficient to pass the failing test
  • When following these rules, all the code you're working on was fully-functional 1 minute ago
  • The unit-tests also function as low-level documentation for the code
  • Test-drive development demo

• Having a good application architecture allows you to defer major decisions