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