Traits, r

[Greg McCarroll]

On Fri, Feb 08, 2008 at 09:10:38AM -0500, Jeff Anderson wrote:
> On Feb 8, 2008 7:39 AM, Ovid <publiustemp-londonpm at yahoo.com> wrote:
> 
> > I'm not claiming that this is an easy thing to really understand, but
> > it's the cleanest way I've encountered of solving hard compositional
> > problems.
> >
> 
> I don't think it is hard to understand at all. It's just that i've
> learned that no matter how clean the solution is, if i don't keep it
> fresh in my mind then after about 3 or so months, it might as well be
> someone else's code.
> 

the solution to this, which i think was suggested by kernighan and plaugher
was to always write code at N% of your ability, where N < 100. it means
that if you have a bad day, or can't remember, or your company hires a less
able programmer - you (or the new maintenance guy) can still get the job done.

i was about to write the following ...

	'i guess it comes down to how clever the guy was before you, if its
	 a great programmer like MJD then even his 50% might be better than
	 my 100%'

then i realised that MJD wouldn't actually write unmaintainable code. and thats 
maybe the example that makes my point.

the trick is if you are using some concept that is new or different make sure you
comment it and clearly show its advantages[1]. even if you have to add URL's to
articles about it. if later it becomes a standard in the community of perl
programmers they can always remove your comments.

perl is a language that gives us huge amounts of freedom and temptation to
do 'clevah' stuff. but a lot of those things should be constrained to fun
YAPC talks and the Acme:: namespace. i've been doing a lot of perl interviews
recently and the same thing always gets said 'large difficult to maintain
code base', and i'm not sure it's the language to blame.

G.

[1] and if you can't explain it clearly and its advantages then you probably
aren't coding at the <100%