'''Anti CopyAndPasteProgramming Measures:''' 

Multiple customised copies of the same code are often ''required'' in games programming to get adequate speed.  What can be done about this?
	* Smart inline expansions could significantly reduce need for programmers to cut and paste.
	* A new diff-like utility could help identify (and merge) near duplications. (see CategoryDuplicationFindingTool for examples)
	* SmallTalk development environment could encourage people to RefactorMercilessly. For example, DynamicTypesEaseRefactoring.
	* Improved Version Control Systems that allow different forks in development to share code fixes better could also help identify duplicated code.
	* Use macros, or even better, use C++ templates, which are really compiler-assisted macros. Templates are nice and fast at runtime if you ask the methods to be inlined, but slow at compile time. Second, OptimizeLater. 

----

'''DNA Analogy''' DNA often holds multiple copies of the same (or similar) gene.  Certain genes can be clearly identified as having arisen from others by gene duplication (and change).  Multi-copy genes, e.g. for Actins (the proteins that make muscle fibres), tend to be ones for which there is high demand, and they tend to occur close to each other in the genome.  Copies seem to be continuously gained and lost.  DNA has its own built in diff-like utility that (seems to) stop duplication getting out of hand.

''Yes; summary termination of the offending organism. Asking evolution for design advice rarely translates into something useful to human designers, who would prefer to avoid the horrid failure rates evolution experiences as a part of its "natural" function.''

----
'''Sometimes no Therapy is best...'''

I don't see much benefit in changing this strcpy() clone on a machine without block transfers:

 while( *src ) 
     *dest++ = *src++;

'''Disagreement (on this example)'''

''I do see benefit in changing this to use strcpy().  It's the compiler's job to optimise the hell out of it.  If the compiler can't, change compilers.  With most compilers, you won't even incur a function call - strcpy is an intrinsic, and runs '''vastly''' faster than the above handcoded loop, especially on RISC processors.''

Change it to use strcpy(), because strcpy is so direct it's almost a comment.  The above code has to be interpreted by the reader.  Granted, it's not tough code to interpret, but let's help the reader out wherever we can.

''Yes.  If the compiler has a good strcpy(), let's use it.  If it's not good enough, let's have the strcpy() code OnceAndOnlyOnce.  Then we can more easily try out alternative representations of strings that allow for faster manipulation. -- Someotherone''

If a machine can do block transfers of memory locations and if a strcpy() routine utilizes this then it will be faster, especially if the strcpy() routine is optimized in assembly for the particular platform (''which it always is, these days''). At the very least, the above function would look better as a macro if it's used in more than one location.

----
[CategoryRefactoring, CategoryGameProgramming]