Inherent code performance advantages of D over C?

Manu turkeyman at gmail.com
Mon Dec 9 18:54:02 PST 2013


On 10 December 2013 11:42, deadalnix <deadalnix at gmail.com> wrote:

> On Sunday, 8 December 2013 at 05:37:09 UTC, H. S. Teoh wrote:
>
>> Or maybe this is just another one of those cultural old age indicators?
>> Has the term "refactoring" shifted to mean "variable renaming" among the
>> younger coders these days? Genuine question. I'm baffled that these two
>> things could even remotely be considered similar things.
>>
>>
> Refactoring is changing your code, without changing what it does. It is
> done in order to make your code easier to understand, more maintainable,
> more testable, or whatever.
>
> Both extracting some code into a function and renaming a variable are
> refactoring operations.
>

With effective semantic analysis, there are many useful refactoring tools
that become possible.
Renaming things is the simplest and probably most common, so it's usually a
good starting point.

Other possibilities for instance:
 * Not just renaming functions, but changing it's signature in general. If
types are changed, then some handling likely needs to be performed (or at
least alerted) at call sites
 * Renaming modules (required when moving source files within the source
tree); update imports, etc.
 * Reordering function parameters automatically reorders terms supplied to
calls of the function (how many times have you wanted to reverse 2 function
parameters, and they've both been int? impossible to update all references
without error)
 * Assignments to delegates may automatically produce an appropriate
function stub, along with typical function name
'On[event-name-being-assigned-to]() { }' or whatever is conventional, and
proper parameters
 * Hilight some text, 'refactor into own function' can move a block of
selected code into a separate function, and correctly update the call site
with the appropriate call, automatically adding function parameters for
previously referenced local variables (seriously, how many times have you
done this, and then carefully had to chase up the locals that are
referenced to build the parameter list?)
 * In addition to the prior point, scan for additional instances of the
code you just refactored, and offer to also replace with calls to the new
function (again, properly hooking up arguments)
 * Auto-magic @property/accessor generation from member variables
 * Auto-magically produce stubs for methods declared in interfaces
 * And many more possibilities...
 * Produce tools to statically encorce project coding standards; ie,
produce red underlines beneath terms in the editor that don't conform to
project standards

If you develop habits around these sorts of tools, you can be far more
productive, and then when they are gone, it feels kinda like trying to use
a mouse without a wheel (ever tried that recently?).
They can also significantly increase the quality of code overall, since
trivial refactoring in many forms becomes an instantaneous operation rather
than wasting programmers working hours. And tools like project coding
standards enforcement will keep the slackers in check.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131210/87e25af5/attachment-0001.html>


More information about the Digitalmars-d mailing list