On the dangers of automated refactoring

[Andre Garzia]

I like verbose code that is full of comments. I often have to revisit code that has been made by me five or even ten years ago, and usually never touched again since then. I need to be able to understand it without relying on my memory from way back when. That is why I often prefer code that is easier to maintain and understand over terse code.

I understand that Jacque is not advocating for terseness, just for doing maintainable small codebases, which is exactly how I like to operate as well. In my mind, if a function is growing longer than the screen, then it is a really good candidate for breaking it up into smaller functions. 

As for the shadowing problem on the codebase I’m working, it is not really by design, it is how the code evolved. Mistakes were made, and now we’re all fixing them. It is just a good example how an attempt of RegEx based refactoring failed because the codebase had gotchas in it that I haven’t noticed before doing extensive refactoring and breaking stuff.

Variable shadowing is a dangerous thing, for me it sits alongside globals as king and queen of the kingdom of "stuff that will come back to haunt you”. 

And that is the main issue: Without a more comprehensive knowledge of the code in a script, you can’t really assume that all variables with the same name, point to the same variable. Trying a "rename symbol” kind of procedure that acts on the whole script, might end up renaming the wrong variables. That is part of what happened to me. This is specially dangerous when globals are involved, as the global is renamed in a script but maybe not in others. In systems that load and unload stacks in demand, you can’t be sure that all occurrences of that global are in memory for you to search, there might be stacks lying on disk that use it that you’re not aware. This can happen on large codebases that are trying to save memory by being smart with what they put in memory. As you can see, this has also happened to us.

> On 14 Apr 2021, at 23:19, Bob Sneidar via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> For my part, I call a function and put the result into a variable. I try not to nest fucntions because I cannot easily tell what the result of each function is, making it harder to troubleshoot, and also to read my own code! For that reason my code is fairly verbose. 
> 
> Bob S
> 
> 
>> On Apr 14, 2021, at 13:06 , Curry Kenworthy via use-livecode <use-livecode at lists.runrev.com> wrote:
>> 
>> Me:
>> 
>>>> The biggest code is the most repetitive and least modular!
>> 
>> Jacqueline:
>> 
>>> Not always, but often. I try to aim for the smallest code base,
>>> so I think the contest should be to solve a complex problem
>>> with the least amount of code.
>> 
>> Yes, but not brevity for its own sake! Rather for maintainability,
>> efficiency, and to avoid the code-org messes that people try to
>> refactor their way out of after practicing bad habits.
>> 
>> The optimal balance of brevity with performance, readability, and maintainability is where we'll find the best code!
>> 
>> That'll be fairly tight code, but not always the very smallest.
>> I do love concise code; I've seen some whopping humongous scripts! :)
>> 
>> Best wishes,
>> 
>> Curry Kenworthy
>> 
>> Custom Software Development
>> "Better Methods, Better Results"
>> LiveCode Training and Consulting
>> http://livecodeconsulting.com/
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode