>>Hi,
>>
>>I am looking for a common sense, good practice advice. I have a BIZ object (for parts) that has 2 methods dealing with updating parts usages. The two methods are as long as the road from here to Alaska, with tons of refactorings (over the years), changes, etc. Managing this code is quite a nightmares. Plus, I believe the code has bugs. But since it is so long, even understanding it would take time (even though I am the creator and have nobody to blame). I used to think that keeping the entire code (with many CASE and IFs) in one method would reduce the maintenance. But it does not seem to work that way.
>>So I am thinking of breaking up these two methods into probably 5-6 small methods, dealing with specific changes/updates.
>>Does this approach make sense?
>>TIA
>
>Thor has tools to split method code into smaller methods.
https://vfpx.codeplex.com/wikipage?title=Thor%20TWEeT%208Thank you.
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham
