Editing Code refactoring (section)

==Techniques==
Here are some examples of micro-refactorings; some of these may only apply to certain languages or language types. A longer list can be found in [[Martin Fowler (software engineer)|Martin Fowler]]'s refactoring book<ref name="fowler">{{cite book|title=Refactoring. Improving the Design of Existing Code|last=Fowler|first=Martin|publisher=Addison-Wesley|year=1999|isbn=978-0-201-48567-7|pages=[https://archive.org/details/isbn_9780201485677/page/63 63ff]|author-link=Martin Fowler (software engineer)|url=https://archive.org/details/isbn_9780201485677/page/63}}</ref>{{page needed|date=July 2018}} and website.<ref name="refactoring.com">(these are only about OOP however).[http://refactoring.com/catalog/index.html Refactoring techniques in Fowler's refactoring Website]</ref> Many development environments provide automated support for these micro-refactorings. For instance, a programmer could click on the name of a variable and then select the "Encapsulate field" refactoring from a [[context menu]]. The IDE would then prompt for additional details, typically with sensible defaults and a preview of the code changes. After confirmation by the programmer it would carry out the required changes throughout the code.
===Static analysis===
[[Static program analysis]] (called "linting" when performed on less strict interpreted languages) detects problems in a valid but substandard program.

* [[Program dependence graph]] - explicit representation of data and control dependencies <ref>
{{Cite journal
|last1=Ferrante|first1=Jeanne
|last2=Ottenstein|first2=Karl J.
|last3=Warren|first3=Joe D.
|date=July 1987
|title= The program dependence graph and its use in optimization
|journal=ACM Transactions on Programming Languages and Systems 
|volume=9
|issue=3
|pages=319–349
|publisher=ACM
|doi=10.1145/24039.24041
|s2cid=505075
|doi-access=free
}}</ref>
* System dependence graph - representation of procedure calls between PDG <ref>
{{Cite conference
|last1=Donglin|first1=Linag
|last2=Harrold|first2=M. J.
|book-title=Proceedings, International Conference on Software Maintenance (Cat. No. 98CB36272)
|title=Slicing objects using system dependence graphs
|date=November 2008
|pages=319–349
|publisher=IEEE
|doi=10.1109/ICSM.1998.738527
|isbn=978-0-8186-8779-2
|s2cid=18160599
}}</ref>
* [[Cyclometric complexity]] analysis.
* [[Software intelligence]] - reverse engineers the initial state to understand existing intra-application dependencies

===Transformations===
Transformations modify the syntactic representation of a program. Some modifications alter the semantics or structure of the program in a way which improves its flexibility or robustness.  Such modifications require knowledge of the problem domain and intended logic, and thus are infeasible to automate. Modifications exist which make the program easier to read and modify but which to not alter the underlying logic of the program; these transformations can be automated.

* Techniques that allow for more [[Abstraction (computer science)|abstraction]]
** [[Field encapsulation|Encapsulate field]] – force code to access the field with getter and setter methods
** [[Type generalization|Generalize type]] – create more general types to allow for more code sharing
** Replace type-checking code with state/strategy<ref>{{cite web| url = http://refactoring.com/catalog/replaceTypeCodeWithStateStrategy.html| title = Replace type-checking code with State/Strategy}}</ref>
** Replace conditional with [[Polymorphism (computer science)|polymorphism]]<ref>{{cite web| url = http://refactoring.com/catalog/replaceConditionalWithPolymorphism.html| title = Replace conditional with polymorphism}}</ref>
* Techniques for breaking code apart into more logical pieces
** Componentization breaks code down into reusable semantic units that present clear, well-defined, simple-to-use interfaces.
** [[Extract class]] moves part of the code from an existing class into a new class.
** Extract method, to turn part of a larger [[method (computer science)|method]] into a new method. By breaking down code in smaller pieces, it is more easily understandable. This is also applicable to [[Function (programming)|function]]s.
* Techniques for improving names and location of code
** Move method or move field – move to a more appropriate [[Class (computer science)|class]] or source file
** Rename method or rename field – changing the name into a new one that better reveals its purpose
** Pull up – in [[object-oriented programming]] (OOP), move to a [[Superclass (computer science)|superclass]]
** Push down – in OOP, move to a [[Subclass (computer science)|subclass]]<ref name="refactoring.com"/>
* Automatic [[clone detection]]<ref>{{cite conference |first1=M. |last1=Bruntink |first2=A. |last2=van Deursen |first3=T. |last3=Tourwe |first4=R. |last4=van Engelen |title=An evaluation of clone detection techniques for crosscutting concerns |book-title=Proceedings, 20th IEEE International Conference on Software Maintenance |publisher=IEEE |date=2004 |doi=10.1109/ICSM.2004.1357804}}</ref>