Re: On the dangers of automated refactoring

[Curry Kenworthy via use-livecode]

Andre:

> I like verbose code that is full of comments.

Ah yes, comments are good! But comments do not make code verbose.
Terse code can be heavily commented, and vice versa.
Commenting is not closely related to my issue, nor perhaps to yours.

Me:

> But there's an even bigger danger than the one already described:
> If a script needs many repeated changes to fix a single problem,
> usually that's because the code was not well-organized and modular.

Among all truly gigantic scripts that perform simple tasks,
usually you find habits of repetitive typing/pasting the same code.

For example, some people like to write out iterations themselves,
rather than using a repeat loop! It's like doing all the leg work.
"Hey Mr. Computer, let me do that for you!" But it creates problems.

Other people take a block of code or a handler for a task, copy it,
paste it, and make a few modifications again for a similar task.
And again. And again. Until there are dozens of similar blocks.

That works great until a problem shows up in one of the blocks.
After fixing it, congrats; only 49 other similar blocks to evaluate!

Each may require the same fix, or a slightly different fix, or none;
because each repeated code block or handler is a unique variation.
This turns what should be a tiny change into a mammoth undertaking. :)

Those are the habits that come back to haunt people later.
They are easy to avoid with good habits, harder to fix down the road!
That's why I'm careful to frequently warn about keeping code modular.

> Trying a "rename symbol” kind of procedure that acts on the
> whole script, might end up renaming the wrong variables.

I agree; it's a problem. Each portion of a script should be handled
with caution, with awareness of context, and with backups in place.
Keyhole surgery, first do no harm, are my approach to operating on code.

Good topic! Back to work

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Andre Garzia via use-livecode]

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 
>  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 
>>  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@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Bob Sneidar via use-livecode]

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 
>  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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Alex Tweedly via use-livecode]

On 14/04/2021 21:01, Ralph DiMola via use-livecode wrote:

Good question... I'm thinking it's the same reason that with strict compilation 
enabled a variable in a repeat loop does not have to be declared as a script 
local. If it is declared as a script local no shadow error occurs. A handler 
parameter in a way is the same as it doesn't need parameters to be declared.

What is the scope of the variable vs. the handler parameter when the handler is 
running? That's bigger question.


The parameter is different from the script-local variable (i.e. changing 
it within the handler changes the parameter, not the script-local).


(and, btw, the same non-reporting happens if it's a global shadowed by a 
parameter name).


Alex.




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Curry Kenworthy via use-livecode]

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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: On the dangers of automated refactoring

[Ralph DiMola via use-livecode]

Good question... I'm thinking it's the same reason that with strict compilation 
enabled a variable in a repeat loop does not have to be declared as a script 
local. If it is declared as a script local no shadow error occurs. A handler 
parameter in a way is the same as it doesn't need parameters to be declared.

What is the scope of the variable vs. the handler parameter when the handler is 
running? That's bigger question.

 
Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
Alex Tweedly via use-livecode
Sent: Wednesday, April 14, 2021 3:39 PM
To: use-livecode@lists.runrev.com
Cc: Alex Tweedly
Subject: Re: On the dangers of automated refactoring


On 14/04/2021 10:23, Andre Garzia via use-livecode wrote:
> That is the main issue, the code was using the wrong hungarian-lite 
> prefixes. You’d see something like
>
>on myHandler pDataA
>  …
>end myHandler
>
>
> But, lo and behold, on top of the script there would be something like
>
>local pDataA
>
> Now, is that an argument to a handler? a script-local? It depends! Strict 
> compilation mode doesn’t care about variable shadowing.

Never mind strict compilation mode, I think this should be a "compile" 
error anyway.

With or without strict-compilation :

   variable shadowing with a script-local and a handler-local is an error.

   variable shadowing with a parameter and a handler-local is an error.

why on earth is variable shadowing between a script-local and a parameter not 
also an error.

Alex.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Alex Tweedly via use-livecode]

On 14/04/2021 10:23, Andre Garzia via use-livecode wrote:

That is the main issue, the code was using the wrong hungarian-lite prefixes. 
You’d see something like

   on myHandler pDataA
 …
   end myHandler


But, lo and behold, on top of the script there would be something like

   local pDataA

Now, is that an argument to a handler? a script-local? It depends! Strict 
compilation mode doesn’t care about variable shadowing.


Never mind strict compilation mode, I think this should be a "compile" 
error anyway.


With or without strict-compilation :

  variable shadowing with a script-local and a handler-local is an error.

  variable shadowing with a parameter and a handler-local is an error.

why on earth is variable shadowing between a script-local and a 
parameter not also an error.


Alex.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[J. Landman Gay via use-livecode]

On 4/13/21 4:07 PM, Curry Kenworthy via use-livecode wrote:


The biggest code is the most repetitive and least modular!


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.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Peter W A Wood via use-livecode]

Thanks Andre

I enjoyed putting the library together though at the time unit testing and 
LiveCode just don’t go together. Personally I find developing with tests gives 
me peace of mind about my code. 

As for refactoring, normally defined as the process of improving code without 
changing it’s behaviour, having a set of tests make it so much more productive.

LiveCode provides a really great platform for unit testing. The language makes 
it so much more simple to write unit tests of GUIs than any other language that 
I know. Even my small testing library could drive a GUI script.

I don’t spend much time with LiveCode these days. I always wanted to explore 
the multimedia capabilities of LiveCode which seem to surfing off into the 
ether. I never really put the time into getting on top of the multimedia 
aspects of LiveCode and, in all probability, lack the creativity to build 
anything of note.

PS Red Lang is going slowly. I haven’t been involved for a while. It’s mainly 
legacy Rebol, JavaScript, a little Lua and more JavaScript work for me these 
days.

> On 13 Apr 2021, at 19:10, Andre Garzia via use-livecode 
>  wrote:
> 
> Peter,
> 
> This is neat!
> 
> I also have a small test library, but mine is way less complete than yours. I 
> never released it because it was quite incomplete.
> 
> Maybe writing a tutorial or doing a small screencast showing it working might 
> help people understand why it is important. I bet many here never used a unit 
> testing library.
> 
> PS: How’s Red Lang going? :D
> 
>> On 13 Apr 2021, at 12:02, Peter W A Wood via use-livecode 
>>  wrote:
>> 
>> Hi Andre
>> 
>>> On 13 Apr 2021, at 18:05, Andre Garzia via use-livecode 
>>>  wrote:
>>> 
>>> We don’t even have unit testing libraries so that we can make sure our code 
>>> works as expected.
>> 
>> I published a simple unit testing library on GitHub but it din’t get any 
>> traction - https://github.com/PeterWAWood/LiveCode-MiniTest 
>> 
>> 
>> Peter
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Andre Garzia via use-livecode]

That is the main issue, the code was using the wrong hungarian-lite prefixes. 
You’d see something like

  on myHandler pDataA
…
  end myHandler


But, lo and behold, on top of the script there would be something like

  local pDataA

Now, is that an argument to a handler? a script-local? It depends! Strict 
compilation mode doesn’t care about variable shadowing.

> On 13 Apr 2021, at 17:48, Richard Gaskin via use-livecode 
>  wrote:
> 
> Andre Garzia wrote:
> 
> > What I didn’t realise was that there was variable shadowing happening
> > in which handler arguments were named with the same name as script-
> > local variables, my smart replacing removed those arguments because
> > there was no need to redeclare the script-local vars. I didn’t realise
> > at that time, that those variables were real arguments being passed to
> > the handlers, they just happened to have the same name as script-local
> > vars in the same script and were in fact shadowing them.
> 
> Is this a case where "Strict Compilation Mode" or Hungarian-lite* notation 
> may have been useful?
> 
> 
> * http://www.fourthworld.com/embassy/articles/scriptstyle.html
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Andre Garzia via use-livecode]

Safety boots are a must for developing safe code.

> On 13 Apr 2021, at 16:48, Bob Sneidar via use-livecode 
>  wrote:
> 
> It's nothing short of a miracle that the shot didn't go INTO your foot. :-) 
> 
> Bob S
> 
> 
>> On Apr 13, 2021, at 03:05 , Andre Garzia via use-livecode 
>>  wrote:
>> 
>> Let me tell you folks a recent story in which I tried to do exactly that and 
>> shot myself on the foot.
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Andre Garzia via use-livecode]

> On 13 Apr 2021, at 16:28, Mark Wieder via use-livecode 
>  wrote:
> 
> Ouch. Don't do that.

I agree, that was not my decision. I maintaining this code but I’m not the 
original developer.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Curry Kenworthy via use-livecode]

Andre:

> Often in LiveCode (and most programming languages to be honest)
> we go coding for a long while and then realise that our code
> need extensive refactoring. We may have repeated a pattern over
> and over again and discovered that we need to change every
> instance of them, or something similar.

Speaking to LC users as a whole rather than Andre in particular,
tools to help with smart refactoring are useful. It all helps.
But there's an even bigger danger than the one already described:

Relying on tech to substitute for good fundamental coding skills.
If a script needs many repeated changes to fix a single problem,
usually that's because the code was not well-organized and modular.

With good coding habits, you will excel with or without such tools.
And when used carefully, they can increase your productivity.
But if you have powerful tools with bad habits, you'll have trouble.

Look at the F-35 stealth fighter, for example. Used in many nations.
Agile coding is a key enabler in the project, but bugs are a problem.
They've had cost increases and delays. Efficient coding is crucial.
Whether jets or vaccines, many lives actually depend on computer code.

In other words, good coding habits are more important than ever.
Software will win or lose wars and determine health outcomes.
You may not be in those line of work, but good habits save headaches!

Well-designed code is a joy to maintain. One problem = one change.
Modular, so that we're not repeating the same code with tiny variations.
There will be cases where old code needs a revision, but much easier.

Bob:

> We should have a contest: Who has the biggest code base.
> Mine's pretty big, but I doubt it's the biggest. :-)

The biggest code is the most repetitive and least modular!
I've seen scripts that were long enough to overwhelm the SE,
yet performed fairly simple tasks. Could be 1/10 the code.

Good topic. Back to work

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Paul Dupuis via use-livecode]

On 4/13/2021 2:39 PM, Mark Wieder via use-livecode wrote:

On 4/13/21 8:37 AM, Paul Dupuis via use-livecode wrote:
I find revRefactor (which adds a Refactoring sub-menu under the Edit 
menu of the IDE Script Editor) to be a tool that I personally would 
like to see better integrated into the IDE.


Paul - thanks for the kind words there.
I took most of your advice and updated the latest build to both github 
and the LiveCodeShare/Online/Sample Stacks... whatever that thing's 
called.


There's now a busy cursor for the Find Orphans feature since it's 
nested repeat loops, and there's a menu item added to the Help menu 
with some minimal help text to jog your memory. I did stop short of 
making it a new menu (vs menuItem)... I think it's more properly a 
subset of the Edit functions, but if you want to play around with it I 
think you'd have to modify the revMenuBar stack. Open to any other 
suggestions.


And it's MIT-licensed, by the way, so anyone can feel free to do what 
they want with it.


https://github.com/mwieder/revRefactor



Wow! Thanks! A terrific tool by the way - and not to deprive any of the 
huge credit you deserve, but features such as your tool are things I 
would expect from the IDE of a "business" edition of LC, hence my 
thought LC, LTD make an arrangement with you to include it in the IDE as 
shipped.



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Paul Dupuis via use-livecode]

On 4/13/2021 12:06 PM, Bob Sneidar via use-livecode wrote:

How do you find that? Github?


Don't remember how I found it - I think an announcement by Mark to the 
list, but, yup, Github:


https://github.com/mwieder/revRefactor

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Mark Wieder via use-livecode]

On 4/13/21 9:48 AM, Richard Gaskin via use-livecode wrote:

Andre Garzia wrote:

 > What I didn’t realise was that there was variable shadowing happening
 > in which handler arguments were named with the same name as script-
 > local variables, my smart replacing removed those arguments because
 > there was no need to redeclare the script-local vars. I didn’t realise
 > at that time, that those variables were real arguments being passed to
 > the handlers, they just happened to have the same name as script-local
 > vars in the same script and were in fact shadowing them.

Is this a case where "Strict Compilation Mode" or Hungarian-lite* 
notation may have been useful?



* http://www.fourthworld.com/embassy/articles/scriptstyle.html



Yep.
But knowing Andre I'll bet he didn't write the original code, just had 
the good fortune to inherit it. 


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Mark Wieder via use-livecode]

On 4/13/21 8:37 AM, Paul Dupuis via use-livecode wrote:
I find revRefactor (which adds a Refactoring sub-menu under the Edit 
menu of the IDE Script Editor) to be a tool that I personally would like 
to see better integrated into the IDE.


Paul - thanks for the kind words there.
I took most of your advice and updated the latest build to both github 
and the LiveCodeShare/Online/Sample Stacks... whatever that thing's called.


There's now a busy cursor for the Find Orphans feature since it's nested 
repeat loops, and there's a menu item added to the Help menu with some 
minimal help text to jog your memory. I did stop short of making it a 
new menu (vs menuItem)... I think it's more properly a subset of the 
Edit functions, but if you want to play around with it I think you'd 
have to modify the revMenuBar stack. Open to any other suggestions.


And it's MIT-licensed, by the way, so anyone can feel free to do what 
they want with it.


https://github.com/mwieder/revRefactor

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Brian Milby via use-livecode]

It was actually more the mis-application of Hungarian-lite.  I think it 
compiled with strict enabled.

Sent from my iPhone

> On Apr 13, 2021, at 12:50 PM, Richard Gaskin via use-livecode 
>  wrote:
> 
> Andre Garzia wrote:
> 
> > What I didn’t realise was that there was variable shadowing happening
> > in which handler arguments were named with the same name as script-
> > local variables, my smart replacing removed those arguments because
> > there was no need to redeclare the script-local vars. I didn’t realise
> > at that time, that those variables were real arguments being passed to
> > the handlers, they just happened to have the same name as script-local
> > vars in the same script and were in fact shadowing them.
> 
> Is this a case where "Strict Compilation Mode" or Hungarian-lite* notation 
> may have been useful?
> 
> 
> * http://www.fourthworld.com/embassy/articles/scriptstyle.html
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Richard Gaskin via use-livecode]

Andre Garzia wrote:

> What I didn’t realise was that there was variable shadowing happening
> in which handler arguments were named with the same name as script-
> local variables, my smart replacing removed those arguments because
> there was no need to redeclare the script-local vars. I didn’t realise
> at that time, that those variables were real arguments being passed to
> the handlers, they just happened to have the same name as script-local
> vars in the same script and were in fact shadowing them.

Is this a case where "Strict Compilation Mode" or Hungarian-lite* 
notation may have been useful?



* http://www.fourthworld.com/embassy/articles/scriptstyle.html

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Bob Sneidar via use-livecode]

How do you find that? Github? 

Bob S


> On Apr 13, 2021, at 08:59 , Paul Dupuis via use-livecode 
>  wrote:
> 
> On 4/13/2021 11:52 AM, Bob Sneidar via use-livecode wrote:
>> We should have a contest: Who has the biggest code base. Mine's pretty big, 
>> but I doubt it's the biggest.:-)
>> 
> ~ 83,000 lines of Livecode script, not counting 3rd party library stacks 
> (Wordlib, Spreadlib, lclSpell, ChartMaker) and some custom externals.
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Paul Dupuis via use-livecode]

On 4/13/2021 11:52 AM, Bob Sneidar via use-livecode wrote:

We should have a contest: Who has the biggest code base. Mine's pretty big, but 
I doubt it's the biggest.:-)

~ 83,000 lines of Livecode script, not counting 3rd party library stacks 
(Wordlib, Spreadlib, lclSpell, ChartMaker) and some custom externals.



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Bob Sneidar via use-livecode]

We should have a contest: Who has the biggest code base. Mine's pretty big, but 
I doubt it's the biggest. :-)

Bob S


> On Apr 13, 2021, at 03:48 , David Bovill via use-livecode 
>  wrote:
> 
> I’d be interested to understand the nature of the gazillion stack project to 
> see how it compares to my gazillion stack project (and I presume others). We 
> could learn things by comparing approaches.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Bob Sneidar via use-livecode]

It's nothing short of a miracle that the shot didn't go INTO your foot. :-) 

Bob S


> On Apr 13, 2021, at 03:05 , Andre Garzia via use-livecode 
>  wrote:
> 
> Let me tell you folks a recent story in which I tried to do exactly that and 
> shot myself on the foot.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Paul Dupuis via use-livecode]

I find revRefactor (which adds a Refactoring sub-menu under the Edit 
menu of the IDE Script Editor) to be a tool that I personally would like 
to see better integrated into the IDE. This plugin was done by Mark 
Wieder and is not an official part of the LiveCode IDE, but it is one 
place, I would very much like to see the mothership either expand on 
Mark's or roll their own, but integrate similar refactoring capabilities 
into the IDE. For example, I frequently forget what some of the menu 
items do and there is no easily accessible built in documentation like 
for much of LiveCode in general. I'd like to see it be more visible - 
its own menu in the script editor or elevated in some way. I have on 
occasion forgot I have it installed and manually renamed a handler when 
revRefactor can doing for me in a few clicks. The "Find Orphan Code" 
feature is really great, but there is not spinning busy cursor or 
progress indicate. Once when running on a old, large code base, I 
thought revFactor had hung as it took so long to display the results. 
I'd pay more for my business license to see these integrated into the 
business edition.



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Mark Wieder via use-livecode]

On 4/13/21 3:05 AM, Andre Garzia via use-livecode wrote:


What I didn’t realise was that there was variable shadowing happening in which 
handler arguments were named with the same name as script-local variables


Ouch. Don't do that.

I end up spending most of my coding life refactoring existing code. And 
while I do automated things, I'm *very* wary about the results if I'm 
working on a large corpus of code: save everything, make a copy of 
everything, save that somewhere else, do the refactor thing, make sure 
it still works, commit to git, rinse and repeat.


Also, if the source is somewhere like dropbox then you have access to 
previous builds as a backup.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Brian Milby via use-livecode]

There is a test framework in the GitHub repository:

https://github.com/livecode/livecode/tree/develop/tests

Didn’t really see documentation on it, but I’m sure it could be documented and 
used to generate a robust unit test of our own projects.  Plenty of examples 
there on use, just nothing on how to easily kick it off for your own projects.

Sent from my iPad

> On Apr 13, 2021, at 6:07 AM, Andre Garzia via use-livecode 
>  wrote:
> 
> Hi Folks,
> 
> I’ve recently read that long thread that almost got people banned and will 
> not comment on it. What I want to comment on is about the kernel of the 
> activity that was mentioned there: refactoring.
> 
> Often in LiveCode (and most programming languages to be honest) we go coding 
> for a long while and then realise that our code need extensive refactoring. 
> We may have repeated a pattern over and over again and discovered that we 
> need to change every instance of them, or something similar.
> 
> There are small cases of refactoring, such as renaming a variable in a single 
> script, that can be easily (and quite safely) be done with find & replace 
> tools. Others are much more complex and attempting to do it over multiple 
> scripts on a large project will result in crying and maybe needing a drink or 
> hug.
> 
> An example of a really smart IDE that is considered the most advanced in 
> terms of refactoring are the ones based on JetBrains IDEA such as IDEA 
> itself, Android Studio, webStorms, etc. A key part of these IDEs to do 
> refactoring is that they have deep knowledge about the source code being 
> written. The code is constantly parsed and assembled in a AST that is exposed 
> internally for the refactoring tools. When you refactor code in these IDEs, 
> you’re not really working with text, you’re telling the IDE to manipulate a 
> tree in ways the IDE knows how to manipulate such tree. That is why when you 
> “rename a symbol” or “extract selected code into method in enclosing scope” 
> or whatever you do in these IDEs, you end up with the expected result.
> 
> Find and Replace dialogs, or even custom plugins in LiveCode, don’t have the 
> same advanced capabilities. You’re usually working with text and hoping that 
> whatever RegEx you’re applying is error-free. And by error-free I don’t mean 
> it is a “valid regex”, I mean that “it does what you expect, and your 
> expectations are correct”. It is very hard to apply script transformations 
> like that, you can’t be sure they’ll work for every little replacement, and 
> for the cases where it doesn’t work, the bugs introduced might be too subtle 
> to notice. Let me tell you folks a recent story in which I tried to do 
> exactly that and shot myself on the foot.
> 
> I’m dealing with a very large LC app. Very large, thousands and thousands of 
> lines spread in a gazilion stacks, behaviors, and libraries. Some of these 
> files needed refactoring. Among the various tasks I needed to do was to apply 
> our “variable naming scheme” to the scripts because there were variables 
> using the wrong prefixes. 
> 
> Naturally, I tried being smart with find & replace. Even going as far as 
> extracting the script into an editor with more features —such as RegEx 
> replacing— and trying my best to identify and replace the names I needed with 
> vast swoops of RegEx.
> 
> All the replacements worked like I wrote them.
> 
> What I didn’t realise was that there was variable shadowing happening in 
> which handler arguments were named with the same name as script-local 
> variables, my smart replacing removed those arguments because there was no 
> need to redeclare the script-local vars. I didn’t realise at that time, that 
> those variables were real arguments being passed to the handlers, they just 
> happened to have the same name as script-local vars in the same script and 
> were in fact shadowing them. 
> 
> I broke all the source code. It took me a long time to work out which 
> handlers needed arguments, and which didn’t need and were actually using the 
> script-local vars.
> 
> I tried being smart fixing broken code, and for a while it became more broken.
> 
> Refactoring is hard.
> 
> We don’t have a system to create and manipulate LC AST.
> 
> We don’t even have unit testing libraries so that we can make sure our code 
> works as expected.
> 
> Avoid large automated refactoring at all cost, it is not worth it. Do it 
> manually. It will be slower, but it will be safer.
> 
> Best
> A
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Mark Smith via use-livecode]

I can't speak for others, but I can personally vouch for the authenticity of 
that statement 😊

On 2021-04-13, 12:12 PM, "use-livecode on behalf of Andre Garzia via 
use-livecode"  wrote:


I bet many here never used a unit testing library.



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Andre Garzia via use-livecode]

Peter,

This is neat!

I also have a small test library, but mine is way less complete than yours. I 
never released it because it was quite incomplete.

Maybe writing a tutorial or doing a small screencast showing it working might 
help people understand why it is important. I bet many here never used a unit 
testing library.

PS: How’s Red Lang going? :D

> On 13 Apr 2021, at 12:02, Peter W A Wood via use-livecode 
>  wrote:
> 
> Hi Andre
> 
>> On 13 Apr 2021, at 18:05, Andre Garzia via use-livecode 
>>  wrote:
>> 
>> We don’t even have unit testing libraries so that we can make sure our code 
>> works as expected.
> 
> I published a simple unit testing library on GitHub but it din’t get any 
> traction - https://github.com/PeterWAWood/LiveCode-MiniTest 
> 
> 
> Peter
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[Peter W A Wood via use-livecode]

Hi Andre

> On 13 Apr 2021, at 18:05, Andre Garzia via use-livecode 
>  wrote:
> 
> We don’t even have unit testing libraries so that we can make sure our code 
> works as expected.

I published a simple unit testing library on GitHub but it din’t get any 
traction - https://github.com/PeterWAWood/LiveCode-MiniTest 


Peter

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: On the dangers of automated refactoring

[David Bovill via use-livecode]

Hence the value of crowd-funding a version of the LiveCode language for the 
Graalvm.

I spend a great deal of my time in LiveCode refactoring and renaming handlers. 
I’ve done this not so much because it is useful to my productivity, but because 
I see a method in the madness of spaghetti code that is worth exploring with 
the tools of collaborative authoring. I’d be interested to understand the 
nature of the gazillion stack project to see how it compares to my gazillion 
stack project (and I presume others). We could learn things by comparing 
approaches.
On 13 Apr 2021, 11:07 +0100, Andre Garzia via use-livecode 
, wrote:
> Hi Folks,
>
> I’ve recently read that long thread that almost got people banned and will 
> not comment on it. What I want to comment on is about the kernel of the 
> activity that was mentioned there: refactoring.
>
> Often in LiveCode (and most programming languages to be honest) we go coding 
> for a long while and then realise that our code need extensive refactoring. 
> We may have repeated a pattern over and over again and discovered that we 
> need to change every instance of them, or something similar.
>
> There are small cases of refactoring, such as renaming a variable in a single 
> script, that can be easily (and quite safely) be done with find & replace 
> tools. Others are much more complex and attempting to do it over multiple 
> scripts on a large project will result in crying and maybe needing a drink or 
> hug.
>
> An example of a really smart IDE that is considered the most advanced in 
> terms of refactoring are the ones based on JetBrains IDEA such as IDEA 
> itself, Android Studio, webStorms, etc. A key part of these IDEs to do 
> refactoring is that they have deep knowledge about the source code being 
> written. The code is constantly parsed and assembled in a AST that is exposed 
> internally for the refactoring tools. When you refactor code in these IDEs, 
> you’re not really working with text, you’re telling the IDE to manipulate a 
> tree in ways the IDE knows how to manipulate such tree. That is why when you 
> “rename a symbol” or “extract selected code into method in enclosing scope” 
> or whatever you do in these IDEs, you end up with the expected result.
>
> Find and Replace dialogs, or even custom plugins in LiveCode, don’t have the 
> same advanced capabilities. You’re usually working with text and hoping that 
> whatever RegEx you’re applying is error-free. And by error-free I don’t mean 
> it is a “valid regex”, I mean that “it does what you expect, and your 
> expectations are correct”. It is very hard to apply script transformations 
> like that, you can’t be sure they’ll work for every little replacement, and 
> for the cases where it doesn’t work, the bugs introduced might be too subtle 
> to notice. Let me tell you folks a recent story in which I tried to do 
> exactly that and shot myself on the foot.
>
> I’m dealing with a very large LC app. Very large, thousands and thousands of 
> lines spread in a gazilion stacks, behaviors, and libraries. Some of these 
> files needed refactoring. Among the various tasks I needed to do was to apply 
> our “variable naming scheme” to the scripts because there were variables 
> using the wrong prefixes.
>
> Naturally, I tried being smart with find & replace. Even going as far as 
> extracting the script into an editor with more features —such as RegEx 
> replacing— and trying my best to identify and replace the names I needed with 
> vast swoops of RegEx.
>
> All the replacements worked like I wrote them.
>
> What I didn’t realise was that there was variable shadowing happening in 
> which handler arguments were named with the same name as script-local 
> variables, my smart replacing removed those arguments because there was no 
> need to redeclare the script-local vars. I didn’t realise at that time, that 
> those variables were real arguments being passed to the handlers, they just 
> happened to have the same name as script-local vars in the same script and 
> were in fact shadowing them.
>
> I broke all the source code. It took me a long time to work out which 
> handlers needed arguments, and which didn’t need and were actually using the 
> script-local vars.
>
> I tried being smart fixing broken code, and for a while it became more broken.
>
> Refactoring is hard.
>
> We don’t have a system to create and manipulate LC AST.
>
> We don’t even have unit testing libraries so that we can make sure our code 
> works as expected.
>
> Avoid large automated refactoring at all cost, it is not worth it. Do it 
> manually. It will be slower, but it will be safer.
>
> Best
> A
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-