Day 23 of 60 (Water Pig): Lightning ⚡️ Talks
Year of the Water Pig
Tonight is the PyWeb Houston meetup and we’re doing ⚡️Talks. I’m doing two. One is related to the code snippet I posted a few days ago. I wanted to look at two different ways to ‘style’ or write your code, depending on what you’re trying to get done.
Background
This is code that takes a JPEG image and converts it into a Base64 encoded ASCII string. This is done to make it easier to attach to a text document. I’ll go into the reasons for why you’d want to do that another time, but this approach was common in the early days of email and it can save space. Plain text is easier to compress. So, here are two ways to write that code.
Style 1: Initial, Verbose
Here we have code you might see after your first pass, when you’re still trying to figure out how to solve the problem. This was MY first pass.
With this approach, each step is layed out clearly.
- Get the path to the image file
- Read that image into
byte_string_hex
- Use base64.b64encode which gives you a Base64-encoded byte string
- Decode that byte string into an ascii string.
- Return the ascii string to the whatever called the function.
Style 2: Refactored, Concise
This is what you might end up with after you refactor your code. You already have a solution to the problem, now you’re trying to make it ‘cleaner’. It’s much more compact.
- Get the path to the image file
- Read that image into
byte_string_hex
- return the converted ascii string
When And Where You Might Use Each Style
Style 1
- When you’re solving a problem for the first time. I think it’s much more important to get something functioning properly first, instead of trying to make it “beautiful” from the start. As you become a more experienced developer, your code will be “more beautiful” from the beginning.
- When you’re trying to explain something to someone less experienced. For teaching purposes, having each step broken out may be more valuable than having the “slickest” code. It also allows you to inspect each step in the transformation process to see what data types are being converted into what other data types.
Style 2
- After you’ve solved your problem. If you’re looking for the cleanest, most concise production code, this is probably the way to go.
- After a refactor. Style 1 still WORKS. But when you go back through to tighten up the code base, that’s the time to look for opportunities to use Style 2.
Update 2017-10-02 21:28
I ended up NOT doing this ⚡️Talk. I did two others instead. I’ll post about one of them later this week.