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.
