harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: RE: Thoughtless fixes considered harmful Was: [OT] Automated fixes considered harmful
Date Tue, 24 Oct 2006 08:41:59 GMT
Hi all,

I agree that code beautifying is a nice thing, But personally I prefer
to do this kind of job manually and only in case if I have the idea
what is this code about. Automated tools suit well for easy tasks like
tabs to spaces replacement and may be code reformating (with caution).
But if the change affects the semantics somehow I always do it by
hands. Just my 0.02$

Thanks,

2006/10/23, Ivanov, Alexey A <alexey.a.ivanov@intel.com>:
> >-----Original Message-----
> >From: Alex Blewitt [mailto:alex.blewitt@gmail.com]
> >Sent: Saturday, October 21, 2006 3:32 AM
> >To: harmony-dev@incubator.apache.org
> >Subject: Re: RE: Thoughtless fixes considered harmful Was: [OT]
> Automated
> >fixes considered harmful
> >
> >On 21/10/06, Fedotov, Alexei A <alexei.a.fedotov@intel.com> wrote:
> >> 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.
> >
> >Completely agree. Code which is fluctuating under development
> >shouldn't cause a concern that it's generating warnings for this kind
> >of thing.
> >
> >Once the code matures, and is fully implemented and tested, *then*
> >that's the time to start the beautification process :-)
> >
>
> I agree with this too. No beautification should be performed on code
> which is actively being developed. I think everybody understands it
> clearly.
>
> But once the code is quite stable and only bug fixes are applied to it,
> I see no harm from deleting unused local variables and imports. Removing
> unreferenced private fields and methods can be dangerous. Nevertheless
> I'd vote for removing ones as well. It makes code more concise leaving
> no legacy.

-- 
Alexei Zakharov,
Intel Enterprise Solutions Software Division

Mime
View raw message