There's the design patterns literature, sometimes fun to just eyeball so you get used to seeing patterns, even if different from the ones described.
In some of my venues, there's a rule against any one person getting to code a whole project i.e. deliberate management strategy to force a minimum of two heads in any one black box, with the thought being, if you have to explain it to me as you go, and I to you, then we won't get away with just "documenting in our heads" (I'll get back to it later). When your counterpart starts saying "I no longer understand this" then you know you've got some rewriting to do. More than two if feasible. Of course that's too much a luxury some maybe thing. Also, don't get me wrong: to collaborate on code is still to write big pieces of it yourself. It's just that the other coder has to be a consumer of your API. Encapsulation: I'm exporting some API for this other coder to use, and once I've put it out there, I should think twice about changing it, lest I break stuff I don't know about... that's a good mentality in general, even if just writing for yourself. Think of the little "dashboards" that makes sense e.g. "increase heartrate" (if a patient object). comp.lang.python also good, any number of friendly people. Programming is hard, if doable. Having collaborators makes it easier in part by adding to the fun. Plus think of coding as a kind of publishing and how academia puts such stress on "peer review" (at least when addressing outsiders). So why should code be any different? You're probably familiar with test driven development (TDD). If not, I'd do some reading. Write tests, lots of them, as you go, partly just as an advertisement to another coder what your API is expected to do. doctest is good, easy. I'd say "every module comes with tests" is a good rule of thumb. This is especially important in Python where so much happens only at runtime, i.e. there's no compile time type checking or stuff of that nature, so writing lots of traps, looking for holes, is a huge time saver in the end. Then stick to the discipline of never committing (publishing, sharing) code that breaks your own tests. A lot of this is "passing on lore" i.e. I've done a lot of solo coding in my day, with no one to explain it to, and test driven development hasn't always been my thing either. However, if you're really seeking more discipline and professionalism in the coding department (as I am, as we all are) then it makes sense to heed what the experts are telling us. In sum: design patterns, TDD / XP. Kirby PS: I also like list comprehensions, use 'em quite a bit. Generators: way cool. Limited experience with scipy distro, suspicious of traits, scared of Zope. Lots of small modules, using __init__.py for package management (ever do that?). On Mon, Apr 6, 2009 at 1:24 PM, Gary Pajer <gary.pa...@gmail.com> wrote: > > On Mon, Apr 6, 2009 at 3:34 PM, kirby urner <kirby.ur...@gmail.com> wrote: >> >> Hey excellent questions Gary, expect others will pipe up. >> >> What I see as a challenge with Python is precisely its liberal nature, >> as coders from earlier generations, cutting teeth in BASIC or FORTRAN, >> find there's sufficient procedural syntax to sort of barrel ahead with >> the same kind of thinking, involving loops within loops, not many >> user-defined classes. > > It would be nice if a discussion ensued, but I'm still a little concerned > that this might not be the right place. > > But to clarify: I've been programming in python for about six years, along > the way abandoning Matlab in which I was a local go-to guy. By the way, > I've also adopted Traits and the Enthought Tool Suite, which IMHO might > possibly be the future of practical laboratory programming in python. So > I'm comfortable enough with the nuts and bolts of OOP. But higher level > questions like what to make a function, what to make a class, what to make a > module, how best to factor it all out, when to decimate a long routine into > a bunch of shorter ones, how best to organize input, computation and output > (Traits' MVC architecture helps there), how to think about designing for > reuse, how to reuse what's already available, when does sub-classing make > sense, when do exceptions make sense... and so on and so on. > > My current habit is to start coding somewhere and keep patching things on > till it does what I want. Imagine building a house starting with "I know I > need at least one upright piece of lumber. I'll put it here. I need > another to hold it up. Then another set over here, and a horizontal one > over there...". I wouldn't want to live in the resulting house. My code > ... the resultant code is hard to follow, hard to document, hard to extend > or change, and probably slower than it might be, and I wouldn't want to live > in that, either. When I try to plan my code the way I might plan a house, > I soon find myself swimming in possible ideas, going in circles with > different plans, having disparate approaches in different parts of the > program, etc. > > I'm wondering if some wizard has written a guide to program structure > paradigms for the intermediate programmer. Or perhaps this kind of thing is > actually taught in books somewhere... > > -gary > _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
