From: Joey Pabalinas <joeypabalinas@gmail.com>
To: Oliver Kiddle <okiddle@yahoo.co.uk>
Cc: "zsh-workers@zsh.org" <zsh-workers@zsh.org>,
Taylor West <KrokodileGlue@outlook.com>
Subject: Re: [RFC] Looking for opinions on accepting refactoring patches
Date: Sat, 17 Mar 2018 13:17:15 -1000 [thread overview]
Message-ID: <20180317231715.dc5zcswwoe5vf2zx@gmail.com> (raw)
In-Reply-To: <7323.1521286049@thecus>
[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]
On Sat, Mar 17, 2018 at 12:27:29PM +0100, Oliver Kiddle wrote:
> I'm sure any improvements would be welcomed. Notions on good
> refactorings can be subjective; such as breaking a long function into
> smaller ones where the original long function was neatly divided
> into self-contained blocks anyway. So as always, it depends on the
> particulars of the patch.
Very true.
> The best way to alleviate the risk of bugs is to add test cases at the
> same time. If you're going through to make sense of the code, test cases
> will occur to you naturally anyway. Running the existing tests with code
> coverage enabled helps to see if code is getting any existing testing.
>
> And if you're willing to fix what you break then I can't see that anyone
> can have any complaints:
Alright, I agree that sounds like best way to manage regression risk. I
most certainly am; it is very depressing when people break things but
force others to fix them.
> It may also help if, when choosing what code to refactor, you have
> a longer term view to some bugs you'd like to see squished or even
> features that might be added.
Very good point as well. This is not something that will be undertaken
lightly; I would have to spend a _LOT_ of time reading the code before
any sort of refactoring is something I would feel comfortable
attempting.
Surgical changes very rarely work for things like this in my opinion;
without the big picture it is very easy to make things worse.
Appreciate the comments; keep it coming guys, thanks.
--
Cheers,
Joey Pabalinas
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-03-17 23:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-16 20:39 Joey Pabalinas
2018-03-17 11:27 ` Oliver Kiddle
2018-03-17 23:17 ` Joey Pabalinas [this message]
2018-03-17 23:39 ` Bart Schaefer
2018-03-18 1:48 ` Joey Pabalinas
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=20180317231715.dc5zcswwoe5vf2zx@gmail.com \
--to=joeypabalinas@gmail.com \
--cc=KrokodileGlue@outlook.com \
--cc=okiddle@yahoo.co.uk \
--cc=zsh-workers@zsh.org \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).