Talk:Code refactoring

This is an old revision of this page, as edited by Henrik S. Hansen (talk | contribs) at 16:16, 22 October 2005. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Latest comment: 19 years ago by Henrik S. Hansen

Can anyone help me on the following sentence? "After a certain point, it becomes clear that functions can benefit from using functions themselves."

I am translating this article to Chinese, but I can't catch it. Thanks.--202.99.60.155 02:11, 17 Jan 2005 (UTC)

It means that it is often useful to break a complex function into calls of less-complex functions. For example, a complex function that reads weather sensors, computes the wheather for next week and produces maps could be broken into three smaller functions that are called in sequence.

--Stephan Leclercq 09:04, 17 Jan 2005 (UTC)

In software engineering, refactoring is *strictly* bound to object oriented code. The term comes from 'factorization'. In OO design, 'to factorize' means 'to distribute responsibilities among classes and objects'.

If you want to talk about behaviour-preserving transformations in structural programs, (or in assembly code or declarative code or whatever) there are other terms, such as 'to restructurize' or 'to reengineer' or similar. Leave refactoring to OOP.

-- Peter

I disagree. Refactoring is not strictly bound to OOP. Refactoring is about behavior-preserving transformations, cleaning code, etc. Concepts that are common to all languages. It is true that some types of refactorings are more or less tied to OO concepts, but refactoring as a whole is not. --Henrik S. Hansen 16:16, 22 October 2005 (UTC)Reply

Which type of testing ensures that refactoring does not change the behavior of the code

Unit tests, especially automated ones in the context of test-first or test-driven development, ensure that refactoring does not change the behavior of the code. The Rod 18:53, 30 September 2005 (UTC)Reply