On 8/27/2011 9:41 AM Roy Smith said...
Chris Angelico<ros...@gmail.com> wrote:
the important
considerations are not "will it take two extra nanoseconds to execute"
but "can my successor understand what the code's doing" and "will he,
if he edits my code, have a reasonable expectation that he's not
breaking stuff". These are always important.
Forget about your successor. Will *you* be able to figure out what you
did 6 months from now? I can't tell you how many times I've looked at
some piece of code, muttered, "Who wrote this crap?" and called up the
checkin history only to discover that *I* wrote it :-)
When you consider that you're looking at the code six months later it's
likely for one of three reasons: you have to fix a bug; you need to add
features; or the code's only now getting used.
So you then take the extra 20-30 minutes, tease the code apart, refactor
as needed and end up with better more readable debugged code.
I consider that the right time to do this type of cleanup.
For all the crap I write that works well for six months before needing
to be cleaned up, there's a whole lot more crap that never gets looked
at again that I didn't clean up and never spent the extra 20-30 minutes
considering how my future self might view what I wrote.
I'm not suggesting that you shouldn't develop good coding habits that
adhere to established standards and result in well structured readable
code, only that if that ugly piece of code works that you move on. You
can bullet proof it after you uncover the vulnerabilities.
Code is first and foremost written to be executed.
Emile
--
http://mail.python.org/mailman/listinfo/python-list
