We needed to start over. Our old app had reached its limits, and we were cutting down on functionality because of it. My team’s old app was extremely tightly coupled with a Microsoft SQL Server Reporting Services (SSRS) server, which had been hacked up to use the web app as a data source and generate reasonably nice-looking reports, and the hackage had determined most of the architecture of the web app code. In addition, despite lots of searching, we could not find a way to get results back from the database without loading them all into memory, using our current framework. We wanted to do large data exports, so that was unacceptable.
Besides, the web app was written in Java. And not good Java—the “Enterprise Java Bean”-filled XML-instantiated messy Java. Yuck.
Building a new web app would enable us to slowly move off of the old app, using the magic of a well-configured load balancer that we already had in place anyway. Our plan was to first build the data export feature, since that would actually have some customer impact. Of course, the wonderful side-effect would be being able to ditch SSRS, which had forever plagued our developers with impossible-to-update code and confusing logic. An app free from the chains of SSRS could be written well and let us build better, more interactive reports. But first, we needed to think about those data exports.
We held a naming contest, and its name from then on would be Data Ex Machina, or DXM for short.
Java’s syntax has been sitting dormant for years. I started writing Java over six years ago, and the major addition since then, as far as I can tell, are generics and the “for each” loop. I’m happy to have these, most of the time, but the more I program in other languages, the more things I miss when I’m back in Java. Some things, like pattern matching for function arguments, I’m never going to get. They just don’t fit into the Java syntax, much less the way that Java’s programming model works. But there are a few things that would be easy enough to integrate into Java that it’s time to put them in.
It’s a trio of suggestions that you’re sure to have heard. Growing up as a kid, I heard this line all the time, from commercials, from school, from my parents.
Reduce, reuse, recycle.
That little triangle with the arrows for corners is burned into my mind for life. Yet, the meaning never really sunk in. To me it all boiled down to the last word: recycle. I learned to separate my normal trash from stuff like bottles, cans, jars, paper, and other things deemed recyclable. To me, that was the epitome of the whole movement.
The first two Rs completely went over my head. I never gave a passing thought to how I might reduce something, or reuse it. When I filled up a paper cup with water, I gulped it down and threw it in the trash can. I can distinctly remember a few times where I would fill a cup, drink it quickly from thirst, throw it out, then go for another cup to fill up, having thrown away the first cup before I realized I was still thirsty. Even though I knew that I should have just kept the first cup, I didn’t worry about it. Can’t do anything about it now, after all.
I never gave a thought to how I might reuse paper cups more than once, like using only one per day instead of four or five. Likewise, I never thought about reducing my use of paper cups to use, for instance, a water bottle. I could use a water bottle for months, at least. But none of that happened. As far as I was concerned, as long as I was putting my aluminum cans in a separate container, I was doing my part for the environment.
And it’s not just me. Plenty of other people missed the message. But recently they’ve started to get it. I see people carrying water bottles around all day. The recent concern for the environment has sparked a movement that people have really gotten behind. Companies and countries now strive to be sustainable. But what does “sustainability” really mean? On the personal level, there’s not much more I can do today to help the environment than there was 20 years ago. I think the main difference is that people are starting to get the other two Rs. Rather than just sorting their waste before they toss it in bins, now people are trying to make less waste in the first place. They’re reducing and reusing. They were important all along, but people understand them now.
As it turns out, the same principles make sense in the world of code. Except this time, it’s not the recycling we’ve all perfected.
My task was refactoring. That is to say, I wasn’t being thrown into the code to make it pretty. I wasn’t just doing superficial things like fixing the names of variables and adding comments. I was making a real change! You see, a bunch of different Python modules all ran separately, and they all had a bunch of slightly different threading code that was essentially the same. So, we got the idea to factor out that functionality, and create one super-elegant abstract class that the separate modules’ classes can use. For kicks, we figured we’d make it so we can run them all at once from a common class.
Sure! Sounds good. Nothing bad I can say about this. I get to put on my smart developer hat, take this crappy code, and make it good.
Then came a suggestion:
While we’re in the code, maybe we should bring it up to PEP 8 compliance!
I thought it was a pretty good idea at the time. Yes! Let’s do that! Then our code will be even better, right? Readable to the max!
The guidelines set out in PEP 8 are actually pretty reasonable. I’ve found that most Python code I’ve written has naturally fallen into the guidelines, with a few notable exceptions, like a habit of writing variable names in mixedCase as opposed to lower_case_with_underscores. Most of PEP 8 is pretty standard stuff, like avoiding extra spaces around parentheses and brackets. Those sort of things.
It’s short too. I mean, it’s more than just a few paragraphs, but it’s no Chicago Manual of Style. You could read it while you ate your sandwich at lunch. Brackets on rye. Mmm.
So what’s my problem with PEP 8?