Like the title describes, I would like to know how you got out of the (bad) habit, particularly when it saves time and does the job.
For further actions, you may consider blocking this person and/or reporting abuse
Like the title describes, I would like to know how you got out of the (bad) habit, particularly when it saves time and does the job.
For further actions, you may consider blocking this person and/or reporting abuse
Judy -
Baltasar GarcΓa Perez-Schofield -
OpenSource -
Abraham Romero -
Top comments (14)
Copying a pattern isn't bad.
Just improve your typing skills by typing it all out manually again.
This will do two things I can think of right now.
First it gives you a chance to
rename
things appropriately, otherwise you tend to forget things and then the code doesn't make sense later.Second, while you type it out you might think to yourself, gee, all I am changing is this or that, perhaps I could make a
common view or function
that both use and then you will have dryer code!I think there are more benefits but these are the two that really stick out to me.
That does make sense. The reason why I thought copying is bad is because I have always thought that creating your own patterns and being able to code out solutions to existing problems are what defines a good developer.
But when you put it into those two perspectives, it does not sound bad at all. Rather, it contributes to the learning process.
Thanks for the input :D
Copying a good pattern isn't bad. I've been developing for over ten years and I still copy good patterns from others. Just make sure you understand what you are copying. Next time you'll be able to use that solution from memory! Or better yet, improve it for your specific need.
I removed the
Ctrl+V
key.Seriously though, copy/pasting code does not save time unless the thing you create is to be used once and thrown away.
Arguments like "saves time and does the job" are really bad. It conflicts with quality. If software is going to be used for other things and for a longer period (which is generally will) then quality is vital.
May I know what you mean by the above statement?
I understand that quality is vital. I believe that the fastest way and ensuring that the software is functional first is more crucial especially when deadlines are due. But perhaps that's more of my newbie mindset kicking in. Still a lot to learn here :)
Prototypes, for example, are used once and thrown away. You use it to prove something is possible (or not), then you throw it away to make a actual solution. Other examples are code/scripts to perform a one-off automation of a task.
It is software which you are not going to maintain. Because it will no longer exist after it has been used.
I don't think I ever got into the habit, except maybe when I was first learning to use a computer and copying code from magazines and books, which doesn't really count.
If I ever copy code from a Stack Overflow answer, I'll invariably have to rewrite it to fit the purpose, or more likely I'll take some sort of inspiration for it and write something more appropriate. Copying more than a line or two at a time seems like a weird idea to me. I'd spend more time trying to figure out why it didn't work than I saved.
Copy/paste is not a good design strategy, but it does have its place. Here is an explanation of the Ginger Cake pattern by Dan North. I can't explain it better than he did in the video. The whole talk is worth watching.
Wow I didn't know there is such a pattern! Thanks a lot for sharing! Learning something new everyday :D
i break down what the language or library is actually doing into small, byte (heh) sized terms i can understand, then i try to recreate everything piece by piece until i have the whole unit.
then i apply it to a bigger project.
for a while i struggled with ecmascript fat-arrow functions. these:
what i did to understand was that i went into open-source code, codeacademy, freecodecamp, etc. code sources and looked at big code, for example, something copied and pasted from a codeacademy page:
when i first saw this, i had some vague idea of where everything was, but i didnt know the specifics. thats what messes you up. always. the specifics. so i looked closely.
so, the function is first declared like a variable, with
const
at the start and a semicolon at the end. alright, ill think of this like a variable.okay, so, after
const
theres a name, just like declaring a variable, as if i declaredconst multiplyByNineFifts = what-the-value-should-be
.its like a variable but dynamic. you can do things with this variable.
what i did after breaking it down like this and understanding it was that i tried converting normal functions into this syntax. for example:
this is taken from the express 2.x start page, because im too lazy to convert the current fat-arrow back to this format.
i broke the function down. im calling
get
onapp
, which is just an alias for tellingexpress
to make a server.get
takes parameters of a route, which is/
, and then a function telling it what to do with this route being used.so this is just like typing
alright, let me convert this to fat-arrow syntax:
let me plug it back in, like with math:
then there was clarity because i took myself through what this whole thing was made of, how to remake it, and what every important part of it did, by thinking about it critically
Let me share my short and hilarious story of getting rid of copying/pasting code:
I haven't, and I won't.
WhyWouldI π
I disagree that copying and pasting code is a bad thing.
There's copying and pasting code mindlessly, and there's doing it smart.
When I copy and paste something, I always make sure to check over it to make sure the quality is up to my standards (don't look at my recent project pls ;-;) and then I make sure it fits seamlessly into my project.
I think it's bad to rely too much on copying and pasting code, but for certain patterns or problems why reinvent the wheel?
I don't see how it is bad.
By appealing to my need to understand things. I just tell myself that I need to understand this thing better and I can usually talk myself into reworking the implementation a bit.