From: Joao Eduardo Luis <joao@suse.de>
To: Sage Weil <sweil@redhat.com>, Wido den Hollander <wido@42on.com>
Cc: Gregory Farnum <gfarnum@redhat.com>,
Loic Dachary <loic@dachary.org>,
"ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Subject: Re: CodingStyle on existing code
Date: Thu, 3 Dec 2015 11:12:32 +0000 [thread overview]
Message-ID: <566023A0.6070506@suse.de> (raw)
In-Reply-To: <alpine.DEB.2.00.1512010717380.19170@cobra.newdream.net>
On 12/01/2015 03:18 PM, Sage Weil wrote:
> On Tue, 1 Dec 2015, Wido den Hollander wrote:
>>
>> On 01-12-15 16:00, Gregory Farnum wrote:
>>> On Tue, Dec 1, 2015 at 5:47 AM, Loic Dachary <loic@dachary.org> wrote:
>>>>
>>>>
>>>> On 01/12/2015 14:10, Wido den Hollander wrote:
>>>>> Hi,
>>>>>
>>>>> While working on mon/PGMonitor.cc I see that there is a lot of
>>>>> inconsistency on the code.
>>>>>
>>>>> A lot of whitespaces, indentation which is not correct, well, a lot of
>>>>> things.
>>>>>
>>>>> Is this something we want to fix? With some scripts we can probably do
>>>>> this easily, but it might cause merge hell with people working on features.
>>>>
>>>> A sane (but long) way to do that is to cleanup when fixing a bug or adding a feature. With (a lot) of patience, it will eventually be better :-)
>>>
>>> Yeah, we generally want you to follow the standards in any new code. A
>>> mass update of the code style on existing code makes navigating the
>>> history a little harder so a lot of people don't like it much, though.
>>
>> Understood. But in this case I'm working in PGMonitor.cc. For just 20
>> lines of code I probably shouldn't refactor the whole file, should I?
While it annoys me finding a given commit in history that just changes
every single line to fix styling, I also recognize that this is the sort
of janitorial task that may be warranted for certain files.
As sage mentions below, this is a low-traffic file. And whenever it's
changed, is often just tiny bits here and there. That tends to add to
the style divergence rather than to convergence.
I'd say go for it. If you are indeed changing those 20 or so lines
though, please add those lines on a separate patch from the style changes.
-Joao
>
> Easiest thing is to fix the code around your change.
>
> I'm also open to a wholesale cleanup since it's a low-traffic file and
> likely won't conflict with other stuff in flight. But, up to you!
>
> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2015-12-03 11:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-01 13:10 CodingStyle on existing code Wido den Hollander
2015-12-01 13:47 ` Loic Dachary
2015-12-01 15:00 ` Gregory Farnum
2015-12-01 15:16 ` Wido den Hollander
2015-12-01 15:18 ` Sage Weil
2015-12-03 11:12 ` Joao Eduardo Luis [this message]
2015-12-09 23:16 ` Wido den Hollander
2015-12-09 23:28 ` Joao Eduardo Luis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=566023A0.6070506@suse.de \
--to=joao@suse.de \
--cc=ceph-devel@vger.kernel.org \
--cc=gfarnum@redhat.com \
--cc=loic@dachary.org \
--cc=sweil@redhat.com \
--cc=wido@42on.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.