my recent commit message responses

[Adam Heath-2]

Ok, as is apparent by the comments I just came up with, there are
issues that are not being discovered.  People aren't reading all
commits, and issues are slipping thru.  If I could find issues with
formatting(which is the bulk of these recent responses), just image
what issues might be in the actual code.

When I am reading a diff, if I see it all nicely formatted, it tends
to also reflect well on the rest of the meat of the patch.

If, however, the change is sloppy, trialing/leading spaces, missing
spaces, typos, random indentation, it tells me that the author
him(her)self was sloppy, so might also have made actual real mistakes
in the code.

As I have mentioned before, I get worried when no one says my stuff is
broken.  I always assume that it is, while trying my best to make
certain it isn't.  You can't know if what you right is correct, as
there may just be some undiscovered bug; maybe your new code isn't
being run at all(but then, how would you have known to add your new
stuff, if it wasn't being run).  But, when a problem actually *is*
found, then I get happy, 'cuz I know my code is actually being used,
and, once the bug gets fixed, things will be better.

[Tim Ruppert]

Thanks for all of your diligence Adam - it makes everything better for the community and I for one appreciate all of the time and expertise that you provide for all of us.  Thanks man.

Cheers,
Ruppert

On Feb 3, 2010, at 10:18 AM, Adam Heath wrote:

> Ok, as is apparent by the comments I just came up with, there are
> issues that are not being discovered.  People aren't reading all
> commits, and issues are slipping thru.  If I could find issues with
> formatting(which is the bulk of these recent responses), just image
> what issues might be in the actual code.
>
> When I am reading a diff, if I see it all nicely formatted, it tends
> to also reflect well on the rest of the meat of the patch.
>
> If, however, the change is sloppy, trialing/leading spaces, missing
> spaces, typos, random indentation, it tells me that the author
> him(her)self was sloppy, so might also have made actual real mistakes
> in the code.
>
> As I have mentioned before, I get worried when no one says my stuff is
> broken.  I always assume that it is, while trying my best to make
> certain it isn't.  You can't know if what you right is correct, as
> there may just be some undiscovered bug; maybe your new code isn't
> being run at all(but then, how would you have known to add your new
> stuff, if it wasn't being run).  But, when a problem actually *is*
> found, then I get happy, 'cuz I know my code is actually being used,
> and, once the bug gets fixed, things will be better.

[Ean Schuessler]

Adam Heath wrote:
> If, however, the change is sloppy, trialing/leading spaces, missing
> spaces, typos, random indentation, it tells me that the author
> him(her)self was sloppy, so might also have made actual real mistakes
> in the code.
>  
I do want to note here that Adam's opinions do not necessarily reflect
mine. I don't lose any sleep over trailing spaces in comments... don't
care about em. Nope.

It does seem like Adam is volunteering to write a really detailed and
comprehensive OFBiz repository style guide page for the Wiki. This
document will, of couse, be based on the best practices from other
projects and the result of calm and reasoned discussion between the
community. Is that correct Adam? Are you volunteering? (If not, you
probably owe the community a whopping dose of STFU)

:-D

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com

[Adam Heath-2]

Ean Schuessler wrote:

> Adam Heath wrote:
>> If, however, the change is sloppy, trialing/leading spaces, missing
>> spaces, typos, random indentation, it tells me that the author
>> him(her)self was sloppy, so might also have made actual real mistakes
>> in the code.
>>  
> I do want to note here that Adam's opinions do not necessarily reflect
> mine. I don't lose any sleep over trailing spaces in comments... don't
> care about em. Nope.
>
> It does seem like Adam is volunteering to write a really detailed and
> comprehensive OFBiz repository style guide page for the Wiki. This
> document will, of couse, be based on the best practices from other
> projects and the result of calm and reasoned discussion between the
> community. Is that correct Adam? Are you volunteering? (If not, you
> probably owe the community a whopping dose of STFU)

However, you fail to realize that everything in my commit comments are
based on either the existing formatting or styles already in the file,
or what others have agreed with me on when I have commented in the past.

Yes, a document that developers could refer to would be great.
However, if people don't read it, we'll be back to this same point.

What's occured in this particular situation, in that people who were
involved in previous discussions about code quality haven't been
following what was agreed to previously.  No matter what, if something
has been agreed to in the past, but then is not followed, don't be
surprised when you get called out on it.

[Adam Heath-2]

Adam Heath wrote:

> Ean Schuessler wrote:
>> Adam Heath wrote:
>>> If, however, the change is sloppy, trialing/leading spaces, missing
>>> spaces, typos, random indentation, it tells me that the author
>>> him(her)self was sloppy, so might also have made actual real mistakes
>>> in the code.
>>>  
>> I do want to note here that Adam's opinions do not necessarily reflect
>> mine. I don't lose any sleep over trailing spaces in comments... don't
>> care about em. Nope.
>>
>> It does seem like Adam is volunteering to write a really detailed and
>> comprehensive OFBiz repository style guide page for the Wiki. This
>> document will, of couse, be based on the best practices from other
>> projects and the result of calm and reasoned discussion between the
>> community. Is that correct Adam? Are you volunteering? (If not, you
>> probably owe the community a whopping dose of STFU)

Oh, and no, *I* won't write such a document.  *We* will write such a
document.