Re: Ranking of OO refactorings

John Carter <[email protected]> Tue, 23 Jul 2013 09:58:28 +1200
Newsgroups gmane.comp.programming.refactoring
Message-ID <CAFD1m3EbXPbSAJyUTMT5CrUOfmytS_5fmNChBCxBWvBv1EMPZA@mail.gmail.com>
> I have looked into D for an embedded ARM environment,


It is exactly for an embedded environment I'm interested in it....


   - Did you have any luck creating a gcd cross compiler? (Which
   host/target OS/CPU?)


   - The usual killer for higher level languages in this environment is the
   non-deterministic timing behaviour caused by the garbage collector. In the
   mathematical sense that is now "A Solved Problem", do you know if they have
   applied those solutions to D?

replace #define
>

W.R.T. your suggested refactorings... they are a little problematic in C....

In C, within global scope declaring a variable "const" means "You can store
this in ROM".

Unfortunately one usually means by "#define CONST nnn"  "I want you to use
this as an 'load immediate' value".

Again, unfortunately the refactoring from an arg macro to an inline can be
problematic since a macro leaks scope in all directions. Usually on the
input side it is not problematic, the compiler tells you variable undefined
and you are prompted to add it to the parameter list.

Where it hurts is when some side effect is created and is used lower down
in the code.

Personally this is a Good Reason to do such clean ups as it removes evil
code. However it becomes a risky thing to do since it requires eyeballing
every line of code downstream within a function of every reference of to
the macro.



On Mon, Jul 22, 2013 at 2:38 PM, J Arrizza <[email protected]> wrote:

> **
>
>
> I have looked into D for an embedded ARM environment, interesting language
> with lots of nice features.
>
> Just wanted to say that the whole "macro abuse" discussion may suggest a
> couple more items to add to your refactoring list:
>
> - replace #define of a manifest constant with a const. If I'm not
> mistaken modern C compilers have a const keyword. This may or may not have
> an effect on executable size or timing.
> - replace #define of a function with either a template or an inline
> function. Again I'm not sure if this would necessarily have an effect on
> the generated executable (but it's highly likely).
>
> John
>
> On Thu, Jul 18, 2013 at 9:27 PM, John Carter <[email protected]
> >wrote:
>
> > **
>
> >
> >
> > The more I think about this problem the more I think C++ is a Bad Idea...
> >
> > And if you think C++ and Refactoring and Automated Refactoring Assistance
> > is a Good Idea... it is probably time you look at giving C++ the heave-ho
> > and skipping on to D.
> >
> > http://dlang.org/pretod.html
> >
> > On Thu, Jul 11, 2013 at 2:35 AM, Richard <[email protected]> wrote:
> >
> > > **
>
> > >
> > >
> > > OK, I've been thinking about the lack of refactoring support for C++
> > > for quite a while now. Compared to IntelliJ for Java and ReSharper for
> > > .NET, the tooling support is relatively weak. So if we were to make a
> > > prioritized list of what's most important for OO refactoring support,
> > > how would we rank the refactorings?
> > >
> > > Here's my top 10, from most important to least important:
> > >
> > > Rename
> > > Extract Constant/Variable/Field
> > > Inline Variable
> > > Invert Conditional
> > > Extract Method
> > > Extract Interface
> > > Split Variable
> > > Move Method
> > > Inline Method
> > > Extract Subclass/Superclass
> > >
> > > How do you rank refactorings?
> > >
> > > Do you have refactorings you consider important that aren't on my top
> 10?
> > >
> > > Do you have a different ranking of the same 10?
> > > --
> > > "The Direct3D Graphics Pipeline" free book <
> > > http://tinyurl.com/d3d-pipeline>
> > > The Computer Graphics Museum <http://computergraphicsmuseum.org>
> > > The Terminals Wiki <http://terminals.classiccmp.org>
> > > Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
> > >
> > >
> >
> > --
> > John Carter
> > Phone : (64)(3) 358 6639
> > Tait Electronics
> > PO Box 1645 Christchurch
> > 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]
>
>  
>



-- 
John Carter
Phone : (64)(3) 358 6639
Tait Electronics
PO Box 1645 Christchurch
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]



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

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] 
    [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/