Skip to main content
deleted 984 characters in body
Source Link
Evan Plaice
  • 5.8k
  • 2
  • 28
  • 34

Bad: Copying and pasting the same block of code over and over again

If you find yourself doing this, you should probably take a second to think about what can be abstracted out of the code being copied and create a function/method to handle it. This is where the DRY (Don't Repeat Yourself) principle counts.

Good: Copying a block of code that's known to work

DRY (Don't Repeat Yourself) also applies here, just in a different sense. IE, don't repeat work you've already done in the past. If you have taken the time to write a section of code, debug, test it, and it's proven to work in a production codebase; you'd be dumb not to re-use it.

Most people give copying-pasting a bad rap because many beginner programmers spend their time scouring the net and copying/pasting a mishmash of other people's code without understanding what it actually does.

Writing everything from scratch every time isn't any better. I know there are a lot of old school purist programmers that thing everything should be written from scratch and I hope I don't get stuck working with them. If you have 5 years of programming experience, you should have a pretty substantial library of code that's prime for re-use. It's one of the best assets an experienced programmer can bring to the table because it'll potentially save a lot of development time.

If you don't understand with your old code does at first, take a moment to read the comments and re-familiarize yourself. If your comments suck... well, that's another issue altogether.

Libraries: Resist the urge

Libraries are only necessary for 2 reasons. One, if the code you wrote is so ubiquitous that it's worth sharing with the rest of the world (or hoarding for yourself). Two, the code is being used across multiple assemblies (IE, the project is multi-process and certain parts are used across more than one process).

If you're thinking about creating a library to cure cancer, make sure an open source library that cures cancer doesn't already exist on the net. Chances are, if it does, it may already cover what you were trying to accomplish. Instead, use the OSS library and invest the time you'd spend rolling your own making the one that already exists more stable.

And... forget the dogma around code methodologies and code smells. People rely on them as a higher power to say, "I'm right and this book is proof that I'm right". Take it all (even what I wrote) as guidelines that allow you to be more conscious of where you could improve.

Bad: Copying and pasting the same block of code over and over again

If you find yourself doing this, you should probably take a second to think about what can be abstracted out of the code being copied and create a function/method to handle it. This is where the DRY (Don't Repeat Yourself) principle counts.

Good: Copying a block of code that's known to work

DRY (Don't Repeat Yourself) also applies here, just in a different sense. IE, don't repeat work you've already done in the past. If you have taken the time to write a section of code, debug, test it, and it's proven to work in a production codebase; you'd be dumb not to re-use it.

Most people give copying-pasting a bad rap because many beginner programmers spend their time scouring the net and copying/pasting a mishmash of other people's code without understanding what it actually does.

Writing everything from scratch every time isn't any better. I know there are a lot of old school purist programmers that thing everything should be written from scratch and I hope I don't get stuck working with them. If you have 5 years of programming experience, you should have a pretty substantial library of code that's prime for re-use. It's one of the best assets an experienced programmer can bring to the table because it'll potentially save a lot of development time.

If you don't understand with your old code does at first, take a moment to read the comments and re-familiarize yourself. If your comments suck... well, that's another issue altogether.

Libraries: Resist the urge

Libraries are only necessary for 2 reasons. One, if the code you wrote is so ubiquitous that it's worth sharing with the rest of the world (or hoarding for yourself). Two, the code is being used across multiple assemblies (IE, the project is multi-process and certain parts are used across more than one process).

If you're thinking about creating a library to cure cancer, make sure an open source library that cures cancer doesn't already exist on the net. Chances are, if it does, it may already cover what you were trying to accomplish. Instead, use the OSS library and invest the time you'd spend rolling your own making the one that already exists more stable.

And... forget the dogma around code methodologies and code smells. People rely on them as a higher power to say, "I'm right and this book is proof that I'm right". Take it all (even what I wrote) as guidelines that allow you to be more conscious of where you could improve.

Bad: Copying and pasting the same block of code over and over again

If you find yourself doing this, you should probably take a second to think about what can be abstracted out of the code being copied and create a function/method to handle it. This is where the DRY (Don't Repeat Yourself) principle counts.

Good: Copying a block of code that's known to work

DRY (Don't Repeat Yourself) also applies here, just in a different sense. IE, don't repeat work you've already done in the past. If you have taken the time to write a section of code, debug, test it, and it's proven to work in a production codebase; you'd be dumb not to re-use it.

Most people give copying-pasting a bad rap because many beginner programmers spend their time scouring the net and copying/pasting a mishmash of other people's code without understanding what it actually does.

Writing everything from scratch every time isn't any better. I know there are a lot of old school purist programmers that thing everything should be written from scratch and I hope I don't get stuck working with them. If you have 5 years of programming experience, you should have a pretty substantial library of code that's prime for re-use. It's one of the best assets an experienced programmer can bring to the table because it'll potentially save a lot of development time.

If you don't understand with your old code does at first, take a moment to read the comments and re-familiarize yourself. If your comments suck... well, that's another issue altogether.

Post Made Community Wiki
Source Link
Evan Plaice
  • 5.8k
  • 2
  • 28
  • 34

Bad: Copying and pasting the same block of code over and over again

If you find yourself doing this, you should probably take a second to think about what can be abstracted out of the code being copied and create a function/method to handle it. This is where the DRY (Don't Repeat Yourself) principle counts.

Good: Copying a block of code that's known to work

DRY (Don't Repeat Yourself) also applies here, just in a different sense. IE, don't repeat work you've already done in the past. If you have taken the time to write a section of code, debug, test it, and it's proven to work in a production codebase; you'd be dumb not to re-use it.

Most people give copying-pasting a bad rap because many beginner programmers spend their time scouring the net and copying/pasting a mishmash of other people's code without understanding what it actually does.

Writing everything from scratch every time isn't any better. I know there are a lot of old school purist programmers that thing everything should be written from scratch and I hope I don't get stuck working with them. If you have 5 years of programming experience, you should have a pretty substantial library of code that's prime for re-use. It's one of the best assets an experienced programmer can bring to the table because it'll potentially save a lot of development time.

If you don't understand with your old code does at first, take a moment to read the comments and re-familiarize yourself. If your comments suck... well, that's another issue altogether.

Libraries: Resist the urge

Libraries are only necessary for 2 reasons. One, if the code you wrote is so ubiquitous that it's worth sharing with the rest of the world (or hoarding for yourself). Two, the code is being used across multiple assemblies (IE, the project is multi-process and certain parts are used across more than one process).

If you're thinking about creating a library to cure cancer, make sure an open source library that cures cancer doesn't already exist on the net. Chances are, if it does, it may already cover what you were trying to accomplish. Instead, use the OSS library and invest the time you'd spend rolling your own making the one that already exists more stable.

And... forget the dogma around code methodologies and code smells. People rely on them as a higher power to say, "I'm right and this book is proof that I'm right". Take it all (even what I wrote) as guidelines that allow you to be more conscious of where you could improve.