[racket-dev] RFC: Coding Guidelines

On Sep  2, Noel Welsh wrote:
> On Sat, Aug 28, 2010 at 5:34 PM, Eli Barzilay <eli at barzilay.org> wrote:
> > I (finally) read this and the thread that went on at the time, and
> > I don't see any point in all of this, besides a vage plea to
> > encourage tests, and a slightly more concrete (but impractical)
> > call for stress tests.
> 
> I think laying down general philosophy is useful. It sets a tone.
> However, I agree with most of your other points though I'm less
> concerned about the ownership of code side, probably 'cause I don't
> have to deal with everyday.

Well -- you do, in a sense.  When something is broken, someone needs
to fix it.  There's tons of stuff that is (or has) bitrotting away
since there's no proper owner to take care of some code, or bugs in
code with no clear owner need to wait for someone to volunteer to do
the work -- and that's less likely to happen.

My worry re ownership is that making a mess there will lead to more of
these problems.  To make a concrete example, there's some unstable
code now that is a big extension to a big library -- and if the
theoretical plan where the unstable manager merges that code in, we
get three people involved: (a) the original author of the library, (b)
the author of the extension, and (c) the unstable manager.  Now what
happens to bugs in the resulting extended library?  To me, this sounds
like a recipe for one of those silly volleyball moments where the
three players stand next to the ball with "I thought *you'd* pick it"
looks.

Because of this, I much rather see such extension getting in by (b)
cooperating with (a) to get the extension in.  With the result being
- (a) making sure he knows all the bits and becoming the owner of
  the result;
- (b) becoming the owner of the resulting extended library;
- or deciding on a clear separation where the two parts are visible
  (possibly involving work on either side), and the two maintain their
  own bits.


> > * "\"Primum non nocere\"" -- after looking this up (bad for such a
> >   document), I strongly disagree with it.  IIUC, it reads as "if
> >   it works, don't mess with it"
> 
> Idiomatically that would be "if it ain't broke, don't fix it". I too
> strongly disagree with this.

(Yeah, I saw that -- and the context that it's coming from is dealing
with a very different kind of machine, where the rules are very
different...)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!