Code refactoring - Revision history

Ed Poor: Already linked earlier in the same paragraph

2025-03-07T22:27:10Z

Already linked earlier in the same paragraph

← Previous revision		Revision as of 22:27, 7 March 2025
Line 3:		Line 3:
	{{About-distinguish\|a behaviour-preserving change\|Rewrite (programming)}}		{{About-distinguish\|a behaviour-preserving change\|Rewrite (programming)}}

	In [[computer programming]] and [[software design]], '''code refactoring''' is the process of restructuring existing [[source code]]—changing the ''[[decomposition (computer science)\|factoring]]''—without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the [[software]] (its ''[[non-functional requirement\|non-functional]]'' attributes), while preserving its [[functional requirement\|functionality]]. Potential advantages of refactoring may include improved code [[readability]] and reduced [[cyclomatic complexity\|complexity]]; these can improve the [[source code~~]]{{~~'}}s [[maintainability]] and create a simpler, cleaner, or more expressive internal [[software architecture\|architecture]] or [[object model]] to improve [[extensibility]]. Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory.		In [[computer programming]] and [[software design]], '''code refactoring''' is the process of restructuring existing [[source code]]—changing the ''[[decomposition (computer science)\|factoring]]''—without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the [[software]] (its ''[[non-functional requirement\|non-functional]]'' attributes), while preserving its [[functional requirement\|functionality]]. Potential advantages of refactoring may include improved code [[readability]] and reduced [[cyclomatic complexity\|complexity]]; these can improve the source code's [[maintainability]] and create a simpler, cleaner, or more expressive internal [[software architecture\|architecture]] or [[object model]] to improve [[extensibility]]. Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory.

	Typically, refactoring applies a series of standardized basic ''micro-refactorings'', each of which is (usually) a tiny change in a computer program's source code that either preserves the behavior of the software, or at least does not modify its conformance to functional requirements. Many [[Development environment (software development process)\|development environments]] provide automated support for performing the mechanical aspects of these basic refactorings. If done well, code refactoring may help software developers discover and fix hidden or dormant [[software bug\|bugs]] or [[vulnerability (computing)\|vulnerabilities]] in the system by simplifying the underlying logic and eliminating unnecessary levels of complexity. If done poorly, it may fail the requirement that external functionality not be changed, and may thus introduce new bugs.		Typically, refactoring applies a series of standardized basic ''micro-refactorings'', each of which is (usually) a tiny change in a computer program's source code that either preserves the behavior of the software, or at least does not modify its conformance to functional requirements. Many [[Development environment (software development process)\|development environments]] provide automated support for performing the mechanical aspects of these basic refactorings. If done well, code refactoring may help software developers discover and fix hidden or dormant [[software bug\|bugs]] or [[vulnerability (computing)\|vulnerabilities]] in the system by simplifying the underlying logic and eliminating unnecessary levels of complexity. If done poorly, it may fail the requirement that external functionality not be changed, and may thus introduce new bugs.

2601:283:4F00:3E0:1431:E95C:8FFB:5C5E at 22:54, 12 February 2025

2025-02-12T22:54:13Z

← Previous revision		Revision as of 22:54, 12 February 2025
Line 232:		Line 232:
	\| title = What is code refactoring?		\| title = What is code refactoring?
	\| url = https://duecode.io/blog/what-is-code-refactoring/		\| url = https://duecode.io/blog/what-is-code-refactoring/
	}}</ref> posthoc to produce concise descriptions of complex software changes recorded in software repositories like ~~CVS or SVN~~.		}}</ref> posthoc to produce concise descriptions of complex software changes recorded in software repositories like [[Git]].

	==Automated code refactoring==		==Automated code refactoring==

Nyq: lc per MOS:EXPABBR and MOS:SECTIONCAPS

2024-12-27T20:30:50Z

lc per MOS:EXPABBR and MOS:SECTIONCAPS

← Previous revision		Revision as of 20:30, 27 December 2024
Line 109:		Line 109:
	==Techniques==		==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.		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 analysis===
	[[Static program analysis]] (called "linting" when performed on less strict interpreted languages) detects problems in a valid but substandard program.		[[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>		* [[Program dependence graph]] - explicit representation of data and control dependencies <ref>
	{{Cite journal		{{Cite journal
	\|last1=Ferrante\|first1=Jeanne		\|last1=Ferrante\|first1=Jeanne
Line 128:		Line 128:
	\|doi-access=free		\|doi-access=free
	}}</ref>		}}</ref>
	* System ~~Dependence~~ ~~Graph~~ - representation of procedure calls between PDG <ref>		* System dependence graph - representation of procedure calls between PDG <ref>
	{{Cite conference		{{Cite conference
	\|last1=Donglin\|first1=Linag		\|last1=Donglin\|first1=Linag

Milo8505: typo (the its -> its)

2024-12-10T08:25:41Z

typo (the its -> its)

← Previous revision		Revision as of 08:25, 10 December 2024
Line 145:		Line 145:

	===Transformations===		===Transformations===
	Transformations modify the syntactic representation of a program. Some modifications alter the semantics or structure of the program in a way which improves ~~the~~ 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.		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]]		* Techniques that allow for more [[Abstraction (computer science)\|abstraction]]

Dissident93: /* Automated code refactoring */

2024-12-06T21:07:19Z

Automated code refactoring

← Previous revision		Revision as of 21:07, 6 December 2024
Line 241:		Line 241:
	** [[Eclipse (software)\|Eclipse]] (for [[Java (programming language)\|Java]], and to a lesser extent, C++, PHP, Ruby and JavaScript)		** [[Eclipse (software)\|Eclipse]] (for [[Java (programming language)\|Java]], and to a lesser extent, C++, PHP, Ruby and JavaScript)
	** [[PyDev]] (for [[Python (programming language)\|Python]])		** [[PyDev]] (for [[Python (programming language)\|Python]])
	** [[Photran]] (a [[Fortran]] plugin for the [[Eclipse (software)\|Eclipse IDE]])
	* [[Embarcadero Delphi]]		* [[Embarcadero Delphi]]
	* IntelliJ based:		* IntelliJ based:
	** [[Resharper]] (for [[C Sharp (programming language)\|C#]])
	** [[AppCode]] (for [[Objective-C]], C and C++)		** [[AppCode]] (for [[Objective-C]], C and C++)
	** [[IntelliJ IDEA]] (for [[Java (programming language)\|Java]])		** [[IntelliJ IDEA]] (for [[Java (programming language)\|Java]])

96.55.138.35: /* Techniques */ Group by analysis and transformations,

2024-11-29T10:32:06Z

Techniques: Group by analysis and transformations,

← Previous revision		Revision as of 10:32, 29 November 2024
Line 109:		Line 109:
	==Techniques==		==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.		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===
	* Techniques that allow for more [[Application discovery and understanding\|understanding]]
			[[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>

		⚫	* [[Program Dependence Graph]] - explicit representation of data and control dependencies <ref>
	{{Cite journal		{{Cite journal
	\|last1=Ferrante\|first1=Jeanne		\|last1=Ferrante\|first1=Jeanne
Line 126:		Line 128:
	\|doi-access=free		\|doi-access=free
	}}</ref>		}}</ref>
	** System Dependence Graph - representation of procedure calls between PDG <ref>		* System Dependence Graph - representation of procedure calls between PDG <ref>
	{{Cite conference		{{Cite conference
	\|last1=Donglin\|first1=Linag		\|last1=Donglin\|first1=Linag
Line 139:		Line 141:
	\|s2cid=18160599		\|s2cid=18160599
	}}</ref>		}}</ref>
			* [[Cyclometric complexity]] analysis.
	** [[Software intelligence]] - reverse engineers the initial state to understand existing intra-application dependencies		* [[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 the 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]]		* Techniques that allow for more [[Abstraction (computer science)\|abstraction]]
	** [[Field encapsulation\|Encapsulate field]] – force code to access the field with getter and setter methods		** [[Field encapsulation\|Encapsulate field]] – force code to access the field with getter and setter methods
Line 155:		Line 162:
	** Push down – in OOP, move to a [[Subclass (computer science)\|subclass]]<ref name="refactoring.com"/>		** 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>		* 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>


	==Hardware refactoring==		==Hardware refactoring==

PrimeBOT: Task 24: elink template removal following a TFD

2024-10-18T23:08:51Z

Task 24: elink template removal following a TFD

← Previous revision		Revision as of 23:08, 18 October 2024
Line 33:		Line 33:
	\|isbn=978-1-4503-9920-3		\|isbn=978-1-4503-9920-3
	}}</ref>		}}</ref>
	# Corrective refactoring – a subsequent developer performs refactoring to correct [[~~Code~~ smell~~\|code smells~~]] as they occur. <ref name="fraivert2022" />		# Corrective refactoring – a subsequent developer performs refactoring to correct [[code smell]]s as they occur.<ref name="fraivert2022" />

	A method that balances preventive and corrective refactoring is "shared responsibility for refactoring".		A method that balances preventive and corrective refactoring is "shared responsibility for refactoring".
	This approach splits the refactoring action into two stages and two		This approach splits the refactoring action into two stages and two
	roles. The original developer of the code just prepares the code for refactoring, and when the [[~~Code~~ smell~~\|code smells~~]] form, a subsequent developer carries out the actual refactoring action. <ref name="fraivert2022" />		roles. The original developer of the code just prepares the code for refactoring, and when the [[code smell]]s form, a subsequent developer carries out the actual refactoring action.<ref name="fraivert2022" />

	==Challenges==		==Challenges==
Line 323:		Line 323:
	*[http://c2.com/cgi/wiki?WhatIsRefactoring What Is Refactoring?] (c2.com article)		*[http://c2.com/cgi/wiki?WhatIsRefactoring What Is Refactoring?] (c2.com article)
	*[http://refactoring.com/ Martin Fowler's homepage about refactoring]		*[http://refactoring.com/ Martin Fowler's homepage about refactoring]
	*{{curlie\|Computers/Programming/Methodologies/Refactoring\|Refactoring}}

	{{Authority control}}		{{Authority control}}

Guy Harris: Use a link that works and that's more likely to continue to work even if the Qt developers reorganize their documentation (it appears they did so, and the result was that the previous link broke).

2024-09-09T19:07:26Z

Use a link that works and that's more likely to continue to work even if the Qt developers reorganize their documentation (it appears they did so, and the result was that the previous link broke).

← Previous revision		Revision as of 19:07, 9 September 2024
Line 251:		Line 251:
	* [[Wing IDE]] (for [[Python (programming language)\|Python]])		* [[Wing IDE]] (for [[Python (programming language)\|Python]])
	* [[Xcode]] (for C, [[Objective-C]], and [[Swift (programming language)\|Swift]])<ref>{{cite web\| url = https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/WhatsNewXcode/xcode_9/xcode_9.html\| title = What's new in Xcode 9}}</ref>		* [[Xcode]] (for C, [[Objective-C]], and [[Swift (programming language)\|Swift]])<ref>{{cite web\| url = https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/WhatsNewXcode/xcode_9/xcode_9.html\| title = What's new in Xcode 9}}</ref>
	* [[Qt Creator]] (for C++, Objective-C and QML)<ref>{{cite web\| url = https://doc.qt.io/qtcreator/creator-~~editor-refactoring~~.html\| title = ~~Refactoring~~ in Qt Creator}}</ref>		* [[Qt Creator]] (for C++, Objective-C and QML)<ref>{{cite web\| url = https://doc.qt.io/qtcreator/creator-overview.html\| title = Overview {{!}} Qt Creator Documentation}}</ref>

	==See also==		==See also==

Guy Harris: Use {{cite conference}} templates for conference papers.

2024-09-09T18:55:52Z

Use {{cite conference}} templates for conference papers.

← Previous revision		Revision as of 18:55, 9 September 2024
Line 23:		Line 23:
	There are two possible times for refactoring.		There are two possible times for refactoring.
	# Preventive refactoring – the original developer of the code makes the code more robust when it is still free of [[Code smell\|smells]] to prevent the formation of smells in the future.<ref name="fraivert2022">		# Preventive refactoring – the original developer of the code makes the code more robust when it is still free of [[Code smell\|smells]] to prevent the formation of smells in the future.<ref name="fraivert2022">
	{{Cite ~~book~~		{{Cite conference
	\|last1=Fraivert\|first1=Dov		\|last1=Fraivert\|first1=Dov
	\|last2=Lorenz\|first2=David H.		\|last2=Lorenz\|first2=David H.
	\|~~chapter~~=Language Support for Refactorability Decay Prevention		\|title=Language Support for Refactorability Decay Prevention
	\|date=2022		\|date=2022
	\|title= Proceedings of the 21st ACM SIGPLAN International Conference on Generative Programming: Concepts and Experiences		\|book-title=Proceedings of the 21st ACM SIGPLAN International Conference on Generative Programming: Concepts and Experiences
	\|pages=122–134		\|pages=122–134
	\|doi=10.1145/3564719.3568688		\|doi=10.1145/3564719.3568688
Line 41:		Line 41:
	==Challenges==		==Challenges==
	Refactoring requires extracting software system structure, data models, and intra-application dependencies to get back knowledge of an existing software system.<ref>		Refactoring requires extracting software system structure, data models, and intra-application dependencies to get back knowledge of an existing software system.<ref>
	{{Cite ~~book~~		{{Cite conference
	\|last1=Haendler\|first1=Thorsten		\|last1=Haendler\|first1=Thorsten
	\|last2=Neumann\|first2=Gustaf		\|last2=Neumann\|first2=Gustaf
	\|title=Proceedings of the 11th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management		\|book-title=Proceedings of the 11th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management
	\|~~chapter~~=A Framework for the Assessment and Training of Software Refactoring Competences		\|title=A Framework for the Assessment and Training of Software Refactoring Competences
	\|s2cid=204754665		\|s2cid=204754665
	\|date=2019		\|date=2019
Line 54:		Line 54:
	}}</ref>		}}</ref>
	The turnover of teams implies missing or inaccurate knowledge of the current state of a system and about design decisions made by departing developers. Further code refactoring activities may require additional effort to regain this knowledge.<ref>		The turnover of teams implies missing or inaccurate knowledge of the current state of a system and about design decisions made by departing developers. Further code refactoring activities may require additional effort to regain this knowledge.<ref>
	{{Cite ~~book~~		{{Cite conference
	\|last1=Nassif\|first1=Matthieu		\|last1=Nassif\|first1=Matthieu
	\|last2=Robillard\|first2=Martin P.		\|last2=Robillard\|first2=Martin P.
	\|~~title~~=2017 IEEE International Conference on Software Maintenance and Evolution (ICSME)		\|conference=2017 IEEE International Conference on Software Maintenance and Evolution (ICSME)
	\|~~chapter~~=Revisiting Turnover-Induced Knowledge Loss in Software Projects		\|title=Revisiting Turnover-Induced Knowledge Loss in Software Projects
	\|s2cid=13147063		\|s2cid=13147063
	\|date=November 2017		\|date=November 2017
Line 80:		Line 80:

	Code refactoring activities are secured with [[software intelligence]] when using tools and techniques providing data about algorithms and sequences of code execution.<ref>		Code refactoring activities are secured with [[software intelligence]] when using tools and techniques providing data about algorithms and sequences of code execution.<ref>
	{{Cite ~~journal~~		{{Cite conference
	\|last1=Hassan\|first1=Ahmed E.		\|last1=Hassan\|first1=Ahmed E.
	\|last2=Xie\|first2=Tao		\|last2=Xie\|first2=Tao
	\|date=November 2010		\|date=November 2010
	\|title=Software intelligence: the future of mining software engineering data		\|title=Software intelligence: the future of mining software engineering data
	\|~~journal~~=In Proceedings of the FSE/SDP Workshop on Future of Software Engineering Research (FoSER '10)		\|book-title=Proceedings of the FSE/SDP Workshop on Future of Software Engineering Research (FoSER '10)
	\|pages=161–166		\|pages=161–166
	\|doi=10.1145/1882362.1882397		\|doi=10.1145/1882362.1882397
Line 127:		Line 127:
	}}</ref>		}}</ref>
	** System Dependence Graph - representation of procedure calls between PDG <ref>		** System Dependence Graph - representation of procedure calls between PDG <ref>
	{{Cite ~~book~~		{{Cite conference
	\|last1=Donglin\|first1=Linag		\|last1=Donglin\|first1=Linag
	\|last2=Harrold\|first2=M. J.		\|last2=Harrold\|first2=M. J.
	\|title=Proceedings. International Conference on Software Maintenance (Cat. No. 98CB36272)		\|book-title=Proceedings, International Conference on Software Maintenance (Cat. No. 98CB36272)
	\|~~chapter~~=Slicing objects using system dependence graphs		\|title=Slicing objects using system dependence graphs
	\|date=November 2008		\|date=November 2008
	\|pages=319–349		\|pages=319–349
Line 154:		Line 154:
	** Pull up – in [[object-oriented programming]] (OOP), move to a [[Superclass (computer science)\|superclass]]		** 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"/>		** Push down – in OOP, move to a [[Subclass (computer science)\|subclass]]<ref name="refactoring.com"/>
	* Automatic [[clone detection]]<ref>~~Bruntink,~~ ~~Magiel,~~ ~~et al~~. ~~"[http://citeseerx~~.~~ist.psu.edu/viewdoc/download?doi~~=10.~~1.1.57.9709&rep~~=~~rep1&type~~=~~pdf~~ An evaluation of clone detection techniques for crosscutting concerns~~]."~~ ~~Software Maintenance~~, ~~2004. Proceedings.~~ 20th IEEE International Conference on. IEEE, 2004.</ref>		* 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>

	==Hardware refactoring==		==Hardware refactoring==

Citation bot: Alter: title, template type. Add: isbn, chapter. Removed parameters. | Use this bot. Report bugs. | Suggested by Headbomb | Linked from Wikipedia:WikiProject_Academic_Journals/Journals_cited_by_Wikipedia/Sandbox | #UCB_webform_linked 122/748

2024-08-12T04:25:23Z

Alter: title, template type. Add: isbn, chapter. Removed parameters. | Use this bot. Report bugs. | Suggested by Headbomb | Linked from Wikipedia:WikiProject_Academic_Journals/Journals_cited_by_Wikipedia/Sandbox | #UCB_webform_linked 122/748

← Previous revision		Revision as of 04:25, 12 August 2024
Line 23:		Line 23:
	There are two possible times for refactoring.		There are two possible times for refactoring.
	# Preventive refactoring – the original developer of the code makes the code more robust when it is still free of [[Code smell\|smells]] to prevent the formation of smells in the future.<ref name="fraivert2022">		# Preventive refactoring – the original developer of the code makes the code more robust when it is still free of [[Code smell\|smells]] to prevent the formation of smells in the future.<ref name="fraivert2022">
	{{Cite ~~journal~~		{{Cite book
	\|last1=Fraivert\|first1=Dov		\|last1=Fraivert\|first1=Dov
	\|last2=Lorenz\|first2=David H.		\|last2=Lorenz\|first2=David H.
		⚫	\|chapter=Language Support for Refactorability Decay Prevention
	\|date=2022		\|date=2022
		⚫	\|title= Proceedings of the 21st ACM SIGPLAN International Conference on Generative Programming: Concepts and Experiences
⚫	\|~~title~~= Language Support for Refactorability Decay Prevention
⚫	\|~~journal~~=Proceedings of the 21st ACM SIGPLAN International Conference on Generative Programming: Concepts and Experiences
	\|pages=122–134		\|pages=122–134
	\|doi=10.1145/3564719.3568688		\|doi=10.1145/3564719.3568688
			\|isbn=978-1-4503-9920-3
	}}</ref>		}}</ref>
	# Corrective refactoring – a subsequent developer performs refactoring to correct [[Code smell\|code smells]] as they occur. <ref name="fraivert2022" />		# Corrective refactoring – a subsequent developer performs refactoring to correct [[Code smell\|code smells]] as they occur. <ref name="fraivert2022" />

← Previous revision		Revision as of 22:27, 7 March 2025
Line 3:		Line 3:
	{{About-distinguish\|a behaviour-preserving change\|Rewrite (programming)}}		{{About-distinguish\|a behaviour-preserving change\|Rewrite (programming)}}

	In [[computer programming]] and [[software design]], '''code refactoring''' is the process of restructuring existing [[source code]]—changing the ''[[decomposition (computer science)\|factoring]]''—without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the [[software]] (its ''[[non-functional requirement\|non-functional]]'' attributes), while preserving its [[functional requirement\|functionality]]. Potential advantages of refactoring may include improved code [[readability]] and reduced [[cyclomatic complexity\|complexity]]; these can improve the [[source code~~]]{{~~'}}s [[maintainability]] and create a simpler, cleaner, or more expressive internal [[software architecture\|architecture]] or [[object model]] to improve [[extensibility]]. Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory.		In [[computer programming]] and [[software design]], '''code refactoring''' is the process of restructuring existing [[source code]]—changing the ''[[decomposition (computer science)\|factoring]]''—without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the [[software]] (its ''[[non-functional requirement\|non-functional]]'' attributes), while preserving its [[functional requirement\|functionality]]. Potential advantages of refactoring may include improved code [[readability]] and reduced [[cyclomatic complexity\|complexity]]; these can improve the source code's [[maintainability]] and create a simpler, cleaner, or more expressive internal [[software architecture\|architecture]] or [[object model]] to improve [[extensibility]]. Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory.

	Typically, refactoring applies a series of standardized basic ''micro-refactorings'', each of which is (usually) a tiny change in a computer program's source code that either preserves the behavior of the software, or at least does not modify its conformance to functional requirements. Many [[Development environment (software development process)\|development environments]] provide automated support for performing the mechanical aspects of these basic refactorings. If done well, code refactoring may help software developers discover and fix hidden or dormant [[software bug\|bugs]] or [[vulnerability (computing)\|vulnerabilities]] in the system by simplifying the underlying logic and eliminating unnecessary levels of complexity. If done poorly, it may fail the requirement that external functionality not be changed, and may thus introduce new bugs.		Typically, refactoring applies a series of standardized basic ''micro-refactorings'', each of which is (usually) a tiny change in a computer program's source code that either preserves the behavior of the software, or at least does not modify its conformance to functional requirements. Many [[Development environment (software development process)\|development environments]] provide automated support for performing the mechanical aspects of these basic refactorings. If done well, code refactoring may help software developers discover and fix hidden or dormant [[software bug\|bugs]] or [[vulnerability (computing)\|vulnerabilities]] in the system by simplifying the underlying logic and eliminating unnecessary levels of complexity. If done poorly, it may fail the requirement that external functionality not be changed, and may thus introduce new bugs.