[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PG: Hackers and Painters

--- "Neil W. Van Dyke" <neil@neilvandyke.org> wrote:
> I think
> they're also some of the most superficial aspects 
> of a programmer's "style."

Agreed they are superficial in-so-far as they don't
contribute to the correctness of code but consistent
formatting is surprinsingly important when reading
code (and many say code should be written to be read).
 For example, recently I was reading someone else's
Scheme code.  That had a consistent regexp-match idiom
they used like so:

(let ((results (regexp-match ...)))
  (unless results (error ...))
  (apply (lambda (...) ...) results))

Now I always write this code like

(match (regexp-match ...)
  [(...) ...]
  [_ (error ...)])

so when I saw the above I thought "ewww, that's a bit
ugly" and emailed the author with my idion.  Is my
idion intrinsically better?  Nope.  It's just what I'm
used to seeing.  In the context of large team
development all that matters is that the team agrees
on common idioms so they can concentrate on the deep
semantics of the code without getting distracted (like
I did) by the surface formatting.

> Analogy: natural language publications have thick
> official style guides,
> yet good writers conforming to those style guides
> have distinct styles
> and strengths


> We tend to embrace these writers' varying strengths
> and perspectives --


> Do the best writers generally write better in pairs?
>  Do we call them
> prima donnas if they claim they think better when
> writing alone?  And
> even if they would write better in pairs, is that
> the best resource
> allocation of our best writers?

That's not all my point.  I simply suggested that
those incapable of agreeing on a *coding style* were
prima donnas as it really isn't that important.  I had
nothing to say about the merits or failures of pair
programming or XP.

But since you brought it up...  There has been actual
research effort (not just hot air! ;-) expended on
studying pair programming:


and the results are generally favourable.  Now of
course these results don't apply to anyone on this
list, because at best they would have studied average
programmers and we are all at least 3 standard
deviations from average, but it does suggest that
those critical of pair programming who yet haven't 
tried it should experiment with an open mind and see
if pair programming can improve their software
development process.  It would be sad to see what may
be a genuine opportunity for improvement missed
because people are too stubborn to try a new idea out
- where would little languages be if everyone had that


Email: noelwelsh <at> yahoo <dot> com
Jabber: noelw <at> jabber <dot> org

Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.