Alex, I see and accept your point. I believe that partial commits are a must - we should be a community.
My point is simple - the code under active development shouldn't be a subject of beautification - it just should be safe for other Harmony modules. The first goal is to make it work. With best regards, Alexei Fedotov, Intel Java & XML Engineering >-----Original Message----- >From: Alex Blewitt [mailto:[EMAIL PROTECTED] >Sent: Saturday, October 21, 2006 3:06 AM >To: harmony-dev@incubator.apache.org >Subject: Re: Thoughtless fixes considered harmful Was: [OT] Automated fixes >considered harmful > >On 20/10/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote: >> >> I agree that if a part of the code is kept for purpose, automatic tools >> can destroy it. From the other side, if we check your example, the >> following commenting solves the problem. >> >> >// int i; >> >// i=someMethod() TODO Fix the bug in someMethod() > >This was a contrived example; the point is, I might be submitting a >checkpoint for the work that I'm doing, and have put the var in there >for a good purpose. For example, it might be a field of a class that >has been put together by design/necessity, even if it's not being used >as of the checkpoint that you're looking at. > >As an obvious case, there are some fields that are defined in the >pack200 class that aren't used yet, mostly because I haven't got >around to the parts in which those aspects are being parsed out. >However, I put them in there as part of the analysis of what was >needed, and I know that they will be used in the near future. There's >no point having them commented out; in fact, whilst coding, I want to >be able to use them via code assist. > >I shouldn't have to sanity check and defend against what others might >do to the code. There's also a similar danger that someone would >remove those comments :-) > >> I have even a stronger suggestion - we should remove the commented code >> leaving only a message for human beings. > >Indeed, that's the big problem. I'm working on that set of code -- it >shouldn't be deleted. It's a work-in-progress. Deleting it and leaving >a message "Your Code Was Here" is counterproductive. > >> I suggest that we better save the time for many readers instead of the >> time of one lazy writer. I'm ok with leaving a human readable message in >> a place of a bug or exceptional behavior. For example, in our case I >> would write: >> >> >// TODO someMethod() behaves weirdly in case of OutOfMyResourceError. >> >// Fix the behavior. > >So, you'd prefer it if I didn't submit code which wasn't 100% >complete? I'm fine with that ... but it'll be a long time before I >complete the spec -- and if someone in the meantime removes some of >the fields that I haven't yet parsed, it will still break when I >update (or any of my further changes are committed). > >A warning does *not* indicate laziness. Nor does wanting to submit >smaller regular patches of incomplete work for others to look at or >improve. However, improvement doesn't include deleting code that >people are still working on. > >Alex.
