I think that the first pass should be treated as if it were the only pass.
That is, don't ignore return codes, and don't ignore structure. Eventually all that
hacking and yelling turns into some angry code, and like you say, you know damn well
you aren't going to come back and refactor. And if you do, it really isn't going to
be fun. And on top of all that, you hate your code.
Even if you're just testing (perhaps especially if you're just testing), don't
ignore errors or logical structure. There have been plenty of times where I have been
led down the wrong path by ignoring return codes that would otherwise tell me exactly
what's going on. For example, if you call the socket( ) function, and ignore the
results, and then your application won't connect, there is a very high degree of
liklihood that it will take you a lot of time to find the error, and you'll be very
pissed off when you finally do. This degree of liklihood really depends on the
code-time between builds, but you get the idea. What you really should be doing is
not only checking the results of socket( ) and throwing exceptions or returning error
codes, but you should be doing this in a way such that flow of control and structure
are satisfactory and pleasing. That is, think about where this exception should be
thrown, who will be catching it, and what they should know (e.g. "conne
ction failed" versus "binding of socket failed").
It's important that you consider your error handling to be of prime importance
in your application. You need to make sure that errors can be properly propagated,
handled, and translated so that the user can deal with them appropriately (e.g. "You
have been disconnected. Reconnect?" This decision is erotically easy to provide,
with proper error propagation code). For example, just last night I had a class that
had a bound method (instance method) that was meant to be executed in a thread (for
network/protocol processing). After I had it all written and working, I took it out
completely. Why? Because if there were an error in that thread, there would be
absolutely no way to handle it: that thread is out of the control of the user, and the
class sure as hell doesn't know where to send it, and even if it did, it wouldn't be
an exception anymore. So, I changed the class to only have a "process" method, which
is called by the user (i.e. the Controller), so that it can actu
ally handle the errors when they occur. If you take such responsibility for your
code, you really can't move on knowing that such a deplorable situation exists in an
otherwise dependable environment. That feeling of necessity and worth is a heck of a
lot better than what it feels like to know you have to change code you wrote in anger
and haste.
On Mon, Oct 25, 2004 at 03:29:53PM -0400, Steven J. Owens wrote:
>
> On Wed, Oct 13, 2004 at 09:20:25AM -0500, Sean Gilbertson wrote:
> > I think a lot can be said for "programming deliberately" rather than
> > programming quickly. I don't know if it's an instinct that can't be
> > faught, or if it's just a lack of responsibility, but I think a lot of
> > code is written quickly, and errors, functionality, and practical
> > structure get ignored.
>
> I've developed a phrase in my vocabulary that I use fairly often,
> "first pass code", i.e. the results of the first pass at the problem.
> You thrash around a little bit and you have to start writing code at
> some point, and pin down parts of the problem to get anywhere.
> Sometimes you take deliberate shortcuts to focus on the larger design
> for now, other times you make sensible design decisions that later
> become obsolete.
>
> Ideally you come back and refactor, but there's a gap between
> reality and the ideal (ideality?). Sometimes I think you just need a
> little distance to come back at it with a fresh perspective. Other
> times it just gets shoved down in the queue repeatedly, until
> eventually it drops off the queue. Then this stuff starts to build up
> and the entropy of the code gets ugly and you start being afraid to
> make changes... :-).
>
> I sometimes think it's inherent in the process, although if I
> understood and did test-driven-development, maybe I wouldn't have as
> many problems with it.
>
> --
> Steven J. Owens
> [EMAIL PROTECTED]
>
> "I'm going to make broad, sweeping generalizations and strong,
> declarative statements, because otherwise I'll be here all night and
> this document will be four times longer and much less fun to read.
> Take it all with a grain of salt." - http://darksleep.com/notablog
>
>
> To Post a message, send it to: [EMAIL PROTECTED]
>
> To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
>
> ad-free courtesy of objectmentor.com
> Yahoo! Groups Links
>
>
>
>
>
>
--
Sean Gilbertson
IT Systems/Software Developer
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
