[Cuis-dev] ExtractMethod improvements

Joel Camera joel.camera at 10pines.com
Thu Jul 30 16:27:00 PDT 2026


Subject: Re: Extract Method improvements in Cuis

Hi Hilaire and Hernán,

Thank you both for the feedback, and thank you for the kind words, Hernán.

Hilaire, I understand your concern. The examples in my original email were
deliberately small so that the mechanics of each improvement were visible,
but I agree they were not the best for evaluating whether the resulting
code is easier to understand in a real-world situation.

The main goal of the assignment block and returning block patterns is not
to suggest that this form is always more readable. Their purpose is to make
the Extract Method possible in cases where it previously failed completely
— because the selected fragment contained assignments to temporary
variables or non-local returns. Before these improvements, you would just
get an error.

I looked carefully at how other environments handle this. Pharo and Squeak
both attempt to extract fragments with assignments and returns, but produce
incorrect results in several cases — wrong return values, unreachable code,
or missing assignments in the caller — and some of those cases end in an
exception. IntelliJ IDEA does better, and I studied it as part of this
work, but it also has cases where the result isn't quite right since it
lacks the full context. My goal was to get this right for Cuis, preserving
the correct semantics in all cases I identified.

In simple cases, the generated code remains as straightforward as before.
These patterns are only introduced when additional machinery is required to
preserve the behavior of the original code, such as when several assigned
variables are still needed by the caller, or when a return occurs from
inside a nested block.

I agree that making a refactoring technically possible does not necessarily
mean that applying it will improve the code. There is a trade-off between
extracting the fragment and introducing additional indirection, and the
developer still needs to evaluate whether the result is clearer in that
particular context. The refactoring provides a valid transformation, but it
does not force the developer to keep it.

The parameterizable code detection is separate from these two patterns. It
only presents structurally similar occurrences as optional candidates, and
the developer can review each one and decide whether introducing parameters
actually improves the code.

I think the best way to see the impact is to use it on real code. With
fewer restrictions, Extract Method will simply work in more situations than
before — and the parameterizable detection will surface patterns that were
previously invisible to the tool.

Best
Joel

<https://10pines.com/>Joel CámeraAgile Software Development

Alem 896, Floor 6, Buenos Aires, Argentina

+54 9 011 6091 3125


El mar, 28 jul 2026 a las 10:53, Hilaire Fernandes via Cuis-dev (<
cuis-dev at lists.cuis.st>) escribió:

> Hi Hernan,
>
> I got situations where method refactoring failed because of the reasons
> mentioned in Joel work. However, the resulting factored code in his example
> afraid me because of a degradation in code understanding. I will test when
> such opportunities arise again.
> Le 27/07/2026 à 21:46, Hernán Wilkinson a écrit :
>
> Hi Hilaire,
>  I think Joel's example isn't effective for understanding its impact on
> real code, it only shows how it works.
>  In a real-life example it is a very useful refactoring. By the way, you
> can decide not to use it and just apply the refactoring only to the
> selected code as before.
>  Joel, maybe you can explain more about that particular improvement of the
> extract method.
>
>  I take the time to congratulate Joel for this work, which is part of his
> master's thesis that he will be defending soon :-) Thanks Joel!!!
>
> -- http://mamot.fr/@drgeo
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260730/5539f7f8/attachment.htm>


More information about the Cuis-dev mailing list