|P is for Practical|
Code that feels goodby scott (Chaplain)
|on Aug 24, 2001 at 22:15 UTC||Need Help??|
I noticed something this morning. Good code feels good - for whatever my definition of good is worth. I had been struggling with the beginnings of a large project and how to handle error conditions. Things were complicated and brittle. Lots of code existed to handle potential problems, obscuring the main goals. I couldn't seem to avoid multiple global variables, it was clear that changing things later would require updates in multiple places, … Things were just generally yucky.
Then I figured out what to do. As I implemented it everything became simple(er) and robust(er). Lines of code dropped, what was left was easier to understand, long range coupling decreased. All was good in the world. (Why it took hours to settle on essentially die and warn and their associated sig handlers is something I'd rather not discuss <sigh>).
But I could literally feel that it was good. The code flowed and the structure was apparent. I didn't have to fight the language or logic. Stuff just happened, and with fewer keystrokes, fewer variables, fewer loops, etc..
The same thing happened earlier when I realized I needed a multilevel hash with coderefs and qr'ed regexes. Once I implemented that, some subs lost half their lines of code. Of course, after the fact, I realized that I was just implementing 'good coding practices' by moving things to data and utilizing features of the language in standard ways. But that was after I did it. The intuition came first, the analysis followed.
This is doubly interesting to me because it jives with how I view what I do in my real life as a graduate student in physics. There is a common view that the sciences proceed in an analytical way, with each step taken for consciously recognized reasons, like the derivation of a mathematical proof. That a researcher sits down at his desk or in front of her experimental apparatus and slowly and relentlessly and logically 'derives' new facts about the world.
From my experience this is complete hogwash. It doesn't work like that at all. What really happens is that you (well, I guess I can only say 'I', can't I?) flounder around in the dark, with vague notions of where you are and where you're going. You try various things that you're not at all sure will work. You try to fit various theories to the problem at hand.
After a few false starts you begin to see how things work, and you try a few more focused experiments and then you understand. Only after that do you construct a specific theory, set up clear and persuasive experiments, and 'derive' your conclusions from commonly accepted axioms.
Well, so much for my ramblings …
Which way do you program? Relentless logical derivation or intuitive-casting-about-with-a-helping-dash-of-pre-and-post-hoc-analysis?
How much time do you spend consciously thinking things like 'I need to decrease coupling', 'This logic is too complicated', etc. and how much time do you just do it and go where your intuition says?