Relearning python, day 2

I got a few hours of python in on Thursday, and had three major breakthroughs.

First, I started using PyCharm, a python IDE from JetBrains, the makers of ReSharper.  I think, in many ways, it is better than Wing- I definitely prefer it.  I have a number of the code analysis, generation, and refactoring tools I was missing, and the IDE behaves more like VS with regards to intellisense and the working environment.  So I feel, once again, like my IDE is helping me.  Now if only I had Edit and Continue in the debugger…

Speaking of which, it made me realize, I need to start writing unit tests (second breakthrough).  I have never written any significant number of unit tests.  It is just a different mentality when you’re writing statically typed code.  Unit testing in python is just something you need to do- and I find it awesome, because I wish I had more incentive to write unit tests in C#.  I expect a lot of my time and resources to be spent learning how to unit test effectively.

The most important breakthrough, though, was realizing how much code I wrote in C# that had a sole job of trying to stop people from doing dumb things.  I read a post on The Endeavour this week titled Software Architecture as a Function of Trust.  It hit exactly what I realized just as I was realizing it.  Thursday morning, I deleted half of all the code I wrote Wednesday.  And, not surprisingly, my entire design was simplified.  Half of all my code was composed of classes that tried to manage what a programmer wanted to do, instead of providing actual functionality.  This is not unlike where I was moving in C#- do as little work as possible in your libraries and ensure the code is passing you valid state/data.  If they’re not, throw an exception as to why not (ie, in few cases would you want to automatically create a directory in your libraries- have the caller test/create it before they call).  In this case, I’m saying- I’m going to do exactly what you ask, and if it doesn’t work, the egg is on your face.  There’s no way to stop bad programmers from writing bad code- anyone can write a bogus implementation of your Interface that perhaps has some logically impossible state.  But what you can do is guide those programmers to use your system correctly, though unit tests and documentation.  Python code is more heavily documented than C# code, hands down.  Even a cursory look at what’s available makes it clear.  These things are part of the language as much as its syntax and grammar.

We forget how powerful of a motivator convention is and try to replace it with oppressive class hierarchies.  I’m much happier with my pythonic design from Thursday than my oppressive and static design from Wednesday.