4 ms·

More than just code duplication, what about functionality duplication? By functionality I mean code that does the same thing but is written significantly differ

More than just code duplication, what about functionality duplication? By functionality I mean code that does the same thing but is written significantly differently. This is by far the most insidious problem as you can't just wrap duplicated code up into a function and move all the code to one place. Usually this problem appears not just as functionality duplicated in many places but each time the functionality is also intertwined with other features and cannot be decomposed to get rid of the duplication. In most styles of programming there is no way to get around this issue as it has to do with program "design." Unless you can make a design that anticipates the duplication, likely a duplication is inevitable. However, if you make your variables immutable as much as possible you can get around this issue and solve what was seemingly a "design" problem but was in fact only a problem with mutable variables. It's too bad the majority of programmers don't know about this.

ksaj 7y ago
This is how Lisp gets you to think about code. Minimize side effects (essentially the same argument as immutable variables), and if you're likely to use something more than once, turn it into its own function. Then stick it into your private library if you're at all likely to see it again in the future. Something that doesn't occur often enough, but should: then rewrite the function for various optimizations - speed, size, security, whatever, while ensuring the same input will always produce the same output.
- crimsonalucard 7y ago
  I'm from the haskell universe. It's more than just side effects. A common design issue people hit is that midway through a projects lifetime they hit a feature request that is basically a slight permutation of an existing feature. They realize that they cannot reuse the code because of the way they "designed" the program. Ideally you want to reuse existing code, or if no function specifically supports this feature you can encapsulate a relevant line of code into some sort of container so that it can be reused in multiple places. This is a way of decomposing your code, or aka: dividing a function into multiple pieces so components can be deployed in multitudes of other location thereby maximizing code re-use. What happens is that most people realize that no matter how much they plan out a design they cannot execute the decomposition procedure above. A design choice made at the inception of the project fixes the shape of the code and limits flexibility. Thus they do code duplication as a workaround hack. I am saying that this problem is actually caused by mutability. What is seemingly a structural problem only occurs because you have a mutable variable. You can cut your code and divide a primitive into a thousand possible pieces if you wanted too but the minute you have a mutable variable in your code the division cannot be done. Think about it. To surgically remove a mutable variable out of a piece of code you must not just cut out the variable but you must also bring every function or procedure that mutates that variable along for the ride. If your function has an entire network of functions mutating procedures than that function cannot be divided into smaller functions. An immutable function can be cut into a thousand pieces and rebuilt in a different way. This is the best known solution for program design and organization.

ksaj 7y ago

This is how Lisp gets you to think about code. Minimize side effects (essentially the same argument as immutable variables), and if you're likely to use something more than once, turn it into its own function. Then stick it into your private library if you're at all likely to see it again in the future. Something that doesn't occur often enough, but should: then rewrite the function for various optimizations - speed, size, security, whatever, while ensuring the same input will always produce the same output.

crimsonalucard 7y ago
I'm from the haskell universe. It's more than just side effects. A common design issue people hit is that midway through a projects lifetime they hit a feature request that is basically a slight permutation of an existing feature. They realize that they cannot reuse the code because of the way they "designed" the program. Ideally you want to reuse existing code, or if no function specifically supports this feature you can encapsulate a relevant line of code into some sort of container so that it can be reused in multiple places. This is a way of decomposing your code, or aka: dividing a function into multiple pieces so components can be deployed in multitudes of other location thereby maximizing code re-use. What happens is that most people realize that no matter how much they plan out a design they cannot execute the decomposition procedure above. A design choice made at the inception of the project fixes the shape of the code and limits flexibility. Thus they do code duplication as a workaround hack. I am saying that this problem is actually caused by mutability. What is seemingly a structural problem only occurs because you have a mutable variable. You can cut your code and divide a primitive into a thousand possible pieces if you wanted too but the minute you have a mutable variable in your code the division cannot be done. Think about it. To surgically remove a mutable variable out of a piece of code you must not just cut out the variable but you must also bring every function or procedure that mutates that variable along for the ride. If your function has an entire network of functions mutating procedures than that function cannot be divided into smaller functions. An immutable function can be cut into a thousand pieces and rebuilt in a different way. This is the best known solution for program design and organization.