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:
signature.asc
Description: PGP signature