"Refactoring" is the phenomenon. Speaking in terms of compression and decompression is not quite exactly the thing, although it can be perfectly cromulent to compress the text or even the AST of a given chunk of code.
Factoring is math.
Consider:
45 * 7 + 60 * 8
We can factor out 15 (which in the case of multiplication is actually called a "factor"):
15 * (3 * 7 + 4 * 8)
And hopefully this expression has better properties (it's either more efficient or shorter or both). There are more involved examples in the WP entry:
https://en.wikipedia.org/wiki/Factorization
Anyway, the point is that when you consider programs as expressions in a symbolic language you can factor out operations (and still know mathematically that your expressions retain their meaning) to look for more mechanically desirable forms.
Typically this looks like "Don't Repeat Yourself" or "Semantic Compression" but it's important to understand that that's the outer form of the technique, its meat and bones are factoring in the mathematical sense.
(I think this point bugs me because DRY is itself a repetition of the concept of refactoring.)
It be well to adopt languages that make it easier to do this sort of thing (besides factoring the other thing you'd want to make easy is applying and unapplying the Futumura Projections.) Forth, Factor, Joy, and the other "concatinative" languages are particularly good for this, although the Lisp family and ML family are good too.
Check out "Compiling to Categories" http://conal.net/papers/compiling-to-categories/ wherein Haskell is transformed to a Point-Free style and interesting things are done with and to the compiler.
- - - -
I couldn't help myself, I golfed this expression a little:
Any compiler that is beyond toy quality reduces that to 795.
So should the programmer; the only reason to leave it in a * b + c * d form would be if it actually looks that way due to symbolic constants being used. The compiler still gets us the 795 so there is no run-time calculation.
Then in that form, there is no common factor to remove: the expressions a and c don't have a common factor.
Of course. I'm just using the simple high school algebra as a kind of metaphor or analogy to the similar concepts and operations in e.g. Lambda Calculus-based PLs. They're formalized in Category Theory but I didn't want to get into all that.
Factoring is math.
Consider:
We can factor out 15 (which in the case of multiplication is actually called a "factor"): And hopefully this expression has better properties (it's either more efficient or shorter or both). There are more involved examples in the WP entry: https://en.wikipedia.org/wiki/FactorizationAnyway, the point is that when you consider programs as expressions in a symbolic language you can factor out operations (and still know mathematically that your expressions retain their meaning) to look for more mechanically desirable forms.
Typically this looks like "Don't Repeat Yourself" or "Semantic Compression" but it's important to understand that that's the outer form of the technique, its meat and bones are factoring in the mathematical sense.
(I think this point bugs me because DRY is itself a repetition of the concept of refactoring.)
It be well to adopt languages that make it easier to do this sort of thing (besides factoring the other thing you'd want to make easy is applying and unapplying the Futumura Projections.) Forth, Factor, Joy, and the other "concatinative" languages are particularly good for this, although the Lisp family and ML family are good too.
Check out "Compiling to Categories" http://conal.net/papers/compiling-to-categories/ wherein Haskell is transformed to a Point-Free style and interesting things are done with and to the compiler.
- - - -
I couldn't help myself, I golfed this expression a little: