refactor for better cleanliness

[arrowtype]

Today, I was lucky enough to talk with Ned Batchelder about ways to improve the code quality in this script. Here are my notes from this, so I can refer to them later as I improve this script further.

---

Computational complexity

• Linear vs quadratic, etc (how do more outputs increase time)

Are there big things you’re doing “wrong”? Not really.

One thing to improve: put functions at the start, then calls at the end

• The “doing lines” could be moved into functions.
• “Only using something once” isn’t a reason to not make a function. It creates a concept for someone reading the code

Classes

• Become useful if you’re dealing with similar kinds of data alongside each other a lot
• e.g. a list of fonts, plus a list of other things to go with the font
• Another sign: many functions that take the same input. e.g. many functions that just take a font object
• Another thing: repeated lines for “full name”
  • The class could define “fontName” once, and then the methods could just call self.fontName

Complexity in report:

• each time you append to a string, you are actually creating a new string (because strings are immutable)
• Opportunity for class: “report”
  • Could have a method “addLine”
  • Could be a list of strings
  • And at the save point, you just join the list with newlines

Opening fonts in a list

• “Classic time-space tradeoff”
• Opening fonts takes a bit of time – not the opening, but the reading

Python memory vs disk memory

• Not really equal
• 20gb of data might not fit into your 32gb system RAM
• You can somewhat see the measurement of python in activity monitor

Is robofont giving you anything special?

• Not really. You could make this a command line tool

conference talk to watch, by Ned: PyCon Computational Complexity

• Big-O: How Code Slows as Data Grows