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/