Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] Collective Code Ownership

Expand Messages
  • Tim Ottinger
    With me it s capitalization. Too little of my life has not included CamelCase, and too much has had conflicting standards for things like acronyms. But I
    Message 1 of 60 , Aug 31, 2007
    • 0 Attachment
      With me it's capitalization. Too little of my life has not included CamelCase, and too much has had conflicting standards for things like acronyms. But I also struggle with not logic booleans. Again, pairs and tests.


      ----- Original Message ----
      From: J. B. Rainsberger <jbrains762@...>
      To: extremeprogramming@yahoogroups.com
      Sent: Thursday, August 30, 2007 1:38:06 PM
      Subject: Re: [XP] Collective Code Ownership

      2chulan@... wrote:

      > ----- Original Message ----
      >
      > ...
      > Here's another simple idea: follow the "Least Qualified Implementer"
      >
      > rule. When it's time to switch pairs, whoever has less experience with
      >
      > the code they're working on switches off.
      >
      > ...
      > ----- Original Message ----
      >
      > Is this correct? If the least experienced person is always switching to
      > other
      > work, doesn't the experienced person end up working on just their specialty?

      Nope. That's my boolean blindspot. I meant the exact opposite. Whoever
      las less experience with the code they're working on /stays/, and the
      other switches off.

      I get booleans backwards all the time. That's one of the many reasons I
      pair and write tests.
      --
      J. B. (Joe) Rainsberger :: http://www.jbrains.ca
      Your guide to software craftsmanship
      JUnit Recipes: Practical Methods for Programmer Testing
      2005 Gordon Pask Award for contribution Agile Software Practice


      To Post a message, send it to: extremeprogramming@...

      To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...

      ad-free courtesy of objectmentor.com
      Yahoo! Groups Links











      ____________________________________________________________________________________
      Pinpoint customers who are looking for what you sell.
      http://searchmarketing.yahoo.com/

      [Non-text portions of this message have been removed]
    • J. B. Rainsberger
      ... I typically put blank lines between the arrange, act and assert parts of my tests, assuming that the whole test is more than a one-liner, but that s the
      Message 60 of 60 , Sep 10, 2007
      • 0 Attachment
        Ron Jeffries wrote:

        > Hello, Chris. On Monday, September 10, 2007, at 3:52:48 AM, you
        > wrote:
        >
        > > I'm with you, Joe: my rule of thumb is that a method that has blank
        > > lines in it either shouldn't have them or is too long.
        >
        > Yes. If there are blank lines in a method that aren't just a
        > mistake, then they are setting off one bit of code from another.
        > Those bits are being set off because they each do something that is
        > a sort of unified step toward some final result. They each embody an
        > "idea".
        >
        > So I'd figure out what that idea is ... and extract a method with
        > that name.

        I typically put blank lines between the arrange, act and assert parts of
        my tests, assuming that the whole test is more than a one-liner, but
        that's the only common exception I can think of.
        --
        J. B. (Joe) Rainsberger :: http://www.jbrains.ca
        Your guide to software craftsmanship
        JUnit Recipes: Practical Methods for Programmer Testing
        2005 Gordon Pask Award for contribution Agile Software Practice
      Your message has been successfully submitted and would be delivered to recipients shortly.