Upgrade to Pro — share decks privately, control downloads, hide ads and more …

What is good code? Evaluating Code Quality (workshop)

What is good code? Evaluating Code Quality (workshop)

I've facilitated this workshop in different communities and events, from October 2017 to June 2018. Companion material (notes, resources…) including slides used in specific editions can be found @ https://github.com/dcarral/good-code.

Workshop summary:

After introducing the main topic (“What is good code?”), participants are asked to solve a simple algorithmic problem (the kata) pairing in their programming language of choice.

Once the coding session is over, it’s time for the “show & discuss” section, where volunteers show and explain their solutions to the group. Together, we discuss tradeoffs, design choices, etc.

Afterwards, concepts like software metrics and static code analysis are gently introduced before discussing even more solutions to the original problem and checking if the numbers align with the previously stated opinions.

The wide range of potential approaches (under slight time pressure, in several programming languages and with different development environments) provides an interesting context to discuss topics like:

– Software development concepts such as duplication tolerance, refactor aggressivity, layers of indirection, conditionals usage, KISS (Keep It Simple, Stupid) / DRY (Don’t Repeat Yourself), etc.

– (XP) eXtreme Programming practices: simple design, pair programming, refactoring, TDD (Test-Driven Development), etc.


Daniel Carral

October 07, 2017

More Decks by Daniel Carral

Other Decks in Programming


  1. What is good code? Evaluating code quality Daniel Carral Barcelona

    on Rails (@ XING), 02/15/2018
  2. None
  3. github.com/dcarral/good-code

  4. Agenda ➔ Intro ➔ Craft Let’s solve the problem! ➔

    Show & discuss Which approach did you use? Why? ➔ Evaluate Opinion vs facts What do the numbers say? ➔ Retrospective
  5. What is good?

  6. None
  7. Good?

  8. None
  9. Good? Better?

  10. None
  11. Craft Coding Dojo

  12. How many dojos?

  13. None
  14. None
  15. TDD & refactoring

  16. Pair programming

  17. Simple design

  18. Kata 99 bottles of beer

  19. Clone & code :) github.com/dcarral/99bottles-polyglot

  20. (until 20:30h) Clone & code :) github.com/dcarral/99bottles-polyglot

  21. Time over :)

  22. Show & discuss (or not ;)

  23. How did you solve it? Why? Reminder The goal is

    not to judge our coding skills. We’re discussing how to evaluate code quality.
  24. github.com/dcarral/99bottles-solutions

  25. Agenda ➔ Intro ➔ Craft Let’s solve the problem! ➔

    Show & discuss Which approach did you use? Why? ➔ Evaluate Opinion vs facts What do the numbers say? ➔ Retrospective
  26. Evaluating code quality

  27. Based on opinion

  28. None
  29. In your opinion, what is “good code”? • “Easy to

    understand and read. Easy to test.” • “SOLID” • “Passes the squint test :)” • “Quality transcends description”
  30. Based on facts

  31. Software metrics “A software metric is a standard measure of

    a degree to which a software system possesses some property.”
  32. Why measure? “You cannot control what you cannot measure.”* —

    Tom DeMarco * Apparently, he regrets having said this (thanks David!)
  33. Some metrics • Ca 1960: LOC • 1976: Cyclomatic complexity

    • 1997: ABC size
  34. ABC • Assignments • Branches (of control) • Conditions

  35. “Confessions of a Ruby Sadist”

  36. 4 more solutions

  37. What do the numbers say? Solution LOC Flog total Flog

    worst bit #1 Incomprehensibly concise 19 42.5 36.2 (#verse) #2 Speculatively general 63 54.8 28.5 (lambdas) #3 Concretely abstract 92 67 15.3 (#challenge) #4 Shameless green 34 25.6 19.3 (#verse)
  38. Why metrics? “Metrics are fallible but human opinion is no

    more precise. Checking metrics regularly will keep you humble and improve your code.” — Sandi Metz, Katrina Owen
  39. None
  40. sandimetz.com/99bottles/postcard

  41. * Disclaimer: Some people don’t like it (at all). Think

    twice before purchasing it ;)
  42. Retro time

  43. … surprised me. I’ve learnt… I’d like to start doing…

    Feedback :)
  44. None
  45. • Coding dojos • TDD • Refactoring • Pair programming

    • Simple design • Zen & the art of motorcycle maintenance • Clean Code • eXtreme Programming explained • 99 bottles of OOP • Beautiful code • Software metrics • LOC • Cyclomatic complexity • ABC size @dcarral dcarral.org