Question about programming habit

[adamantine.me]

For a specific situation - say you have a working method/ main method but need to apply that solution to a couple other tables/arrays/objects/whatevers. Basically when you're tempted to copy/paste code and change the variable names where needed. Do you just copy/pasta or actually retype it? I find if you try to save time by copy pasting, you end up with syntactically correct but semantically incorrect code which is often more time consuming to debug than just a few syntax errors.

 

[KB]

If the code is reusable it should never be copied and pasted or retyped. Instead find a way to make it reusable with only one copy of the code. The best way to do this is with object inheritance. Have all objects that will use the code inherit from a class that contains the code.
Another way to do it would be to implement a single class containing the desired method. This method can takes a series of primitive parameters or object parameters (for example String tablename or Array) and act on the parameters in a standard way.

 

[purbeast0]

As KB Mentioned, copying code is a very bad habit. Either create a class that has the common functionality and extend from it, or create a "static" class with the method in it so that you can call it from anywhere. I put "static" in quotes because I basically am referring to a singleton class, and it's different how you create those based on the language/environment you are in.

I'm also not really following what you mean by saying the solution works for multiple things but you have to change variable names. I'd think if the same solution/logic can be reused, then you wouldn't want to change variable names since well, it's the same logic and solution for both. If it's a function that say does the same thing but you can pass in a "cat" or a "dog", then simply name the variable "animal". Make the names more generic to match all cases.

 

[Red Squirrel]

If I feel myself doing something repetitive I always try to take a step back and look at an OOP way of doing it. Such as creating one or more classes or breaking down the task into reusable units. Really depends on how/if I anticipate the program to grow in size. Initially it can take longer and more effort to code proper OOP so if it's a quick app I know is going to not need to grow much I might cheat.

I will usually just copy and paste, and not actually rewrite it, in that case.

 

[DaveSimmons]

I do copy-paste as a starting point sometimes. Usually when the logic is almost the same but not quite (so shared code won't work), and it is only needed in a couple of places. And yes, now and then that has gone horribly wrong

But one copy-paste fail out of 10-15+ was acceptable for the time saved, and so was not making class(es) to abstract out the common parts and then specializing -- that usually makes sense for ten uses, but not always for two. And the layers of OOP can add their own bugs.

I like to think I've built up a decent feel for the trade-offs after many years of doing this.

 

[Cogman]

I'm with Dave on this. Once upon a time I was all for base classes, but they have bitten me. Then I turned to static classes, and they two have taken their toll.

I don't see copy and paste as a jump off point being the worst thing in the world. Heck, sometimes it is a necessity when you want just a small bit of functionality from a library and not the whole thing with all of its sub dependencies.

I find myself today relying heavily on dependency injection and composition to get work done. I've seen too many problems created by inheritance to want to touch it. I'm sure there are some good applications for it, but I find that often things that aught not be in the base class end up getting hoisted more for convenience then anything else.