Re: Fwd: Compiler Guided Refactoring.

I'm not a 100% sure, but I believe Michael Feathers is talking about a
dependency graph (i.e. what code depends on what).

What I'm saying here is to use a DAG (like those used by compiler
optimizers):

http://en.wikipedia.org/wiki/Directed_acyclic_graph

BTW I did a quick search and found nothing open source or immediately
available, although there probably is one buried in the gcc optimizer...



On Tue, Jul 9, 2013 at 10:58 PM, Andrew McDonagh
<[email protected]>wrote:

> **
>
>
> This topic is covered in Michael Feathers book: Working With Legacy Code.
>
> Regards
> Andrew
>
>
> On 10 Jul 2013, at 05:07, J Arrizza <[email protected]> wrote:
>
> > John, I may be beating a dead horse here, but I'm going to throw it out
> > there anyway.
> >
> > I remember vaguely from a comp-sci course that a flow-graph can be
> > generated from source, and in your case from the generated assembly cod=
e.
> > Comparing the before and after flow-graphs would give you a true/false =
as
> > to functional equivalence of a refactoring operation. But I'm pretty su=
re
> > that flow-graphs do not include timing.
> >
> > So here's the pitch: extend the concept of a flow-graph to tally the
> timing
> > on the branches of the graph. Then the before/after comparison would gi=
ve
> > you both functional and timing equivalence. Sounds like a pain, but it
> > might make a nice master's thesis.
> >
> > Not sure what exactly this would bring to the table, but it would --
> > potentially -- allow some refactorings to occur that a strict diff of t=
he
> > before/after executables would not. From a practical perspective, you'd
> > have to trust the theory and also the utility that generates the
> > flow-graphs, of course.
> >
> > Bottom line: Is it worth the effort? no idea....
> >
> > John
> >
> > On Mon, Jul 8, 2013 at 3:54 PM, J Arrizza <[email protected]> wrote:
> >
> >> On Mon, Jul 8, 2013 at 3:02 PM, John Carter <[email protected]
> >wrote:
> >>
> >>> **
>
> >>>
> >>>
> >>>> The key aspect to the Extract Method with no arguments and void retu=
rn
> >>>> value (i.e. void-void extraction) is that it minimizes the risk of
> >>>> introducing side-effects.
> >>>
> >>> That is what appeals to me most about it....
> >>>
> >>> However, it is steps a largish notch away from the idea... ie. Tweaki=
ng
> >>> the Declarations to Tighten the constraints enforced by the compiler.
> >>>
> >>> I see, so the code is that critical... You're looking for absolutely =
no
> >> change in the generated executable but still refactorings on the sourc=
e.
> >>
> >>> ie. Your void-void is low risk, provided the person doing the
> refactoring
> >>> doesn't,,,
> >>> * accidentally reorder something,
> >>> * drop a step,
> >>> * or extract copypasta into a single method that isn't copypasta but
> >>> copypasta and tiny easily missed tweak.
> >>>
> >>> :) copy and pasta, had it for supper last night.
> >>
> >> I wonder if there is any way of doing a reliable cross check, or a
> variant
> >>> of this, or a way of injecting additional steps to increase safety.
> >>>
> >>> So clearly UTs are not available. What about Pair Programming? Or cod=
e
> >> review after a small set of changes?
> >> On the other hand, if the code is as critical as it seems to be, even
> >> those won't guarantee no changes in the executable.
> >>
> >> Hmm. It might need an additional check, gcc will always inline somethi=
ng
> >>> like that so could diff the disassembly output.
> >> Sure, it could be used in lieu of UTs:
> >> - If the disassembly output matches, then all is well.
> >> - If they don't match, then a quick review of the disassembly output a=
nd
> >> the source to see why the mismatch. A mismatch might still be
> acceptable,
> >> right??
> >>
> >> On the bright side... you might find a compiler bug.
> >>
> >>
> >>> On Sun, Jul 7, 2013 at 5:31 AM, J Arrizza <[email protected]> wrote:
> >>>
> >>>> The key aspect to the Extract Method with no arguments and void retu=
rn
> >>>> value (i.e. void-void extraction) is that it minimizes the risk of
> >>>> introducing side-effects.
> >>>>
> >>>> The conversion of the function parameters to consts is slightly
> >>> different,
> >>>> its purpose is to highlight the fact that the function won't
> introduce a
> >>>> side-effect via those parameters.
> >>>
> >>>>
> >>>> Further to this, one additional refactoring I've used is Rename
> >>> Variable to
> >>>> add a "g" prefix to all global variables. I personally don't like
> >>> hungarian
> >>>> notation but adding the "g" is a very useful exception to this rule.
> All
> >>>> the globals show up clearly in the code.
> >>>>
> >>>> One other way to achieve this is to put all globals into a single
> struct
> >>>> called "globals". Then all uses show up as "globals.some_variable"
> which
> >>>> makes it very clear that there is a global side-effect in that part =
of
> >>> the
> >>>> code. But note the compiler may generate more code for this techniqu=
e.
> >>>>
> >>>> John
> >>>
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Jul 4, 2013 at 3:28 PM, J Arrizza <[email protected]> wrote=
:
> >>>>
> >>>>> On Thu, Jul 4, 2013 at 7:27 AM, Richard <[email protected]>
> >>> wrote:
> >>>>>
> >>>>>> **
> >>>>>>
> >>>>>> n article <
> >>>>>> CAEyOLyBfwH6uD6Z5RxBmmne4NA90cpF6N6LGacJPmRTSz7Enyg@mail.gmail.com
> >,
> >>>
> >>>>>> J Arrizza <[email protected]> writes:
> >>>>>>
> >>>>>>> is. IMO the biggest bang for buck is the void-void extraction.
> >>>>>>
> >>>>>> This is Extract Method/Extract Function with no arguments
> >>>>> ... and void return value.
> >>>>>
> >>>>>>> The next best is the void-const extraction.
> >>>>>
> >>>>>> This is Extract Method/Extract Function with arguments
> >>>>> ... and void return value and all the arguments are const.
> >>>>>
> >>>>>>
> >>>>>> I think it's important to use the established names for well known
> >>>>>> refactorings for clear communication.
> >>>>> Absolutely.
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Start a New Topic<
> >>>
> http://groups.yahoo.com/group/refactoring/post;_ylc=3DX3oDMTJlazgzdWgyBF9=
TAzk3MzU5NzE0BGdycElkAzM5NzU2MDIEZ3Jwc3BJZAMxNzA3Mjc2NzE4BHNlYwNmdHIEc2xrA2=
50cGMEc3RpbWUDMTM3Mjk0ODA2Ng--
> >>>>
> >>>> Messages
> >>>>>> in this topic<
> >>>
> http://groups.yahoo.com/group/refactoring/message/10661;_ylc=3DX3oDMTM2dT=
Y1ZDY3BF9TAzk3MzU5NzE0BGdycElkAzM5NzU2MDIEZ3Jwc3BJZAMxNzA3Mjc2NzE4BG1zZ0lkA=
zEwNjY0BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTM3Mjk0ODA2NgR0cGNJZAMxMDY2MQ--
> >>>>> (4)
> >>>>>> Recent Activity:
> >>>>>>
> >>>>>>
> >>>>>> Visit Your Group<
> >>>
> http://groups.yahoo.com/group/refactoring;_ylc=3DX3oDMTJlOW1ucG5jBF9TAzk3=
MzU5NzE0BGdycElkAzM5NzU2MDIEZ3Jwc3BJZAMxNzA3Mjc2NzE4BHNlYwN2dGwEc2xrA3ZnaHA=
Ec3RpbWUDMTM3Mjk0ODA2Ng--
> >>>>>
> >>>>>> [image: Yahoo! Groups]<
> >>>
> http://groups.yahoo.com/;_ylc=3DX3oDMTJkbWt0N2dqBF9TAzk3MzU5NzE0BGdycElkA=
zM5NzU2MDIEZ3Jwc3BJZAMxNzA3Mjc2NzE4BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxMzcyOTQ4=
MDY2
> >>>>>
> >>>>>> Switch to: Text-Only<
> >>>> [email protected]
> >>> ?subject=3DChange+Delivery+Format:+Traditional
> >>>>> ,
> >>>>>> Daily Digest<
> >>>> [email protected]?subject=3DEmail+Delivery:+Digest>=
=95
> >>>>>> Unsubscribe <
> >>>> [email protected]?subject=3DUnsubscribe>=95 Te=
rms
> >>>>>> of Use <http://docs.yahoo.com/info/terms/> =95 Send us Feedback
> >>>>>> <
> >>>> [email protected]
> >>> ?subject=3DFeedback+on+the+redesigned+individual+mail+v1
> >>>>>
> >>>>>> .
> >>>>
> >>>>
> >>>> [Non-text portions of this message have been removed]
> >>>>
> >>>>
> >>>>
> >>>> ------------------------------------
> >>>>
> >>>> Yahoo! Groups Links
> >>>
> >>> --
> >>> John Carter Phone : (64)(3) 358 6639
> >>> Tait Electronics Fax : (64)(3) 359 4632
> >>> PO Box 1645 Christchurch Email : [email protected]
> >>> New Zealand
> >>>
> >>> --
> >>>
> >>> ------------------------------
> >>> This email, including any attachments, is only for the intended
> >>> recipient.
> >>> It is subject to copyright, is confidential and may be the subject of
> >>> legal
> >>> or other privilege, none of which is waived or lost by reason of this
> >>> transmission.
> >>> If you are not an intended recipient, you may not use, disseminate,
> >>> distribute or reproduce such email, any attachments, or any part
> thereof.
> >>> If you have received a message in error, please notify the sender
> >>> immediately and erase all copies of the message and any attachments.
> >>> Unfortunately, we cannot warrant that the email has not been altered =
or
> >>> corrupted during transmission nor can we guarantee that any email or
> any
> >>> attachments are free from computer viruses or other conditions which
> may
> >>> damage or interfere with recipient data, hardware or software. The
> >>> recipient relies upon its own procedures and assumes all risk of use
> and
> >>> of
> >>> opening any attachments.
> >>> ------------------------------
> >>>
> >>>
> >>> [Non-text portions of this message have been removed]
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
>=20=20
>


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected]=20
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/