On 10 December 2013 11:42, deadalnix <deadal...@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.