<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 10 December 2013 11:42, deadalnix <span dir="ltr"><<a href="mailto:deadalnix@gmail.com" target="_blank">deadalnix@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sunday, 8 December 2013 at 05:37:09 UTC, H. S. Teoh wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Or maybe this is just another one of those cultural old age indicators?<br>
Has the term "refactoring" shifted to mean "variable renaming" among the<br>
younger coders these days? Genuine question. I'm baffled that these two<br>
things could even remotely be considered similar things.<br>
<br>
</blockquote>
<br></div>
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.<br>
<br>
Both extracting some code into a function and renaming a variable are refactoring operations.<br>
</blockquote></div><br></div><div class="gmail_extra">With effective semantic analysis, there are many useful refactoring tools that become possible.</div><div class="gmail_extra">Renaming things is the simplest and probably most common, so it's usually a good starting point.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Other possibilities for instance:</div><div class="gmail_extra"> * 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</div>
<div class="gmail_extra"> * Renaming modules (required when moving source files within the source tree); update imports, etc.</div><div class="gmail_extra"> * 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)</div>
<div class="gmail_extra"> * 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</div>
<div class="gmail_extra"> * 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?)</div>
<div class="gmail_extra"> * 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)</div>
<div class="gmail_extra"> * Auto-magic @property/accessor generation from member variables</div><div class="gmail_extra"> * Auto-magically produce stubs for methods declared in interfaces</div><div class="gmail_extra"> * And many more possibilities...</div>
<div class="gmail_extra"> * Produce tools to statically encorce project coding standards; ie, produce red underlines beneath terms in the editor that don't conform to project standards</div><div class="gmail_extra"><br>
</div><div class="gmail_extra">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?).</div>
<div class="gmail_extra">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.</div>
</div>