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

[XP] Re: Collective Code Ownership

Expand Messages
  • Rob Park
    If it were as simple as having the IDE reformat, I don t think I d mind once in a while having to manually tell it to Format Document , but this doesn t help
    Message 1 of 60 , Aug 31, 2007
    View Source
    • 0 Attachment
      If it were as simple as having the IDE reformat, I don't think I'd
      mind once in a while having to manually tell it to "Format Document",
      but this doesn't help with:
      * extraneous whitespace
      * poor method/variable names
      * for vs. foreach
      * ICollection vs. IList
      * etc...

      .rob.

      --- In extremeprogramming@yahoogroups.com, "Steven Gordon"
      <sgordonphd@...> wrote:
      >
      > In order to make diffs meaningful, pick a format for storing in
      version
      > control and have the IDE convert to that format before check in.
      >
      > On 8/31/07, Brad Stiles <bradley.stiles@...> wrote:
      > >
      > > Steven Gordon <sgordonphd@... <sgordonphd%40gmail.com>> wrote:
      > >
      > > > Because I and others can only abide one style of bracketing,
      some
      > > > other people can only abide a different style of bracketing, and
      > > > the IDE can convert any code we open to the style of bracketing
      > > > either party prefers.
      > >
      > > Do you use version control to store your source? If so, do you
      find
      > > that revisions to source code contain, in addition to the
      substantive
      > > changes that occur when adding features, many differences related
      only
      > > to formatting changes? If so, do you not find it annoying as all
      get
      > > out to have to wade through all that crap to find an actual
      meaningful
      > > difference?
      > >
      > > Brad
      > >
      > >
      > >
      >
      >
      > [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
      View Source
      • 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.