3 ms·

I'm surprised by the number of people who don't see this as a problem. I've worked pretty recently as the most senior developer on a team, and I saw tons of is

I'm surprised by the number of people who don't see this as a problem. I've worked pretty recently as the most senior developer on a team, and I saw tons of issues caused by copy/pasted code. It results in a lot of issues. Subtle bugs around `==` versus `===` in JavaScript, unecessary variables that obfuscate the code, Python that isn't Pythonic, C that was written as an example and therefore doesn't include the error handling that is constantly necessary in C (how many C examples check the return value of malloc?). The biggest problem, I think, is that often you end up with 10 different ways to solve the same problem in the code because instead of looking at the existing code, people Googled for a solution with subtly different keywords than the previous person and found a different blogger. This kind of duplication is very hard to identify and remove, and this does cause bugs. Of course a more experienced developer can work around these issues, but a more experienced developer also knows off the top of their head how to write the code themselves and usually does it.

bentcorner 12y ago
> The biggest problem, I think, is that often you end up with 10 different ways to solve the same problem in the code because instead of looking at the existing code, people Googled for a solution with subtly different keywords than the previous person and found a different blogger. This kind of duplication is very hard to identify and remove, and this does cause bugs. It's interesting to code in large code bases. They end up getting to the point where no single person can ever understand the entire thing. It is usually at this point that things like Hungarian and strict coding guidelines really help. If you need an array of pointers to some kind of object, you can be reasonable certain that search will be able to find it.
- woah 12y ago
  IMO if your code base is large, you have already failed.
  - copsarebastards 12y ago
    If your code base is large, you've failed as a coder. If your code base never gets large, you've failed as a company.
- copsarebastards 12y ago
  I think that sometimes Hungarian notation and strict coding guidelines can help, but more and more I think that there's no way to effectively enforce those things unless you automate them from the beginning. I've worked on very effective teams, where nothing ever got checked into master without two sets of eyes on it, strict rules were followed, etc., and there are always holes from lack of automation and legacy code. Automation helps: linters, static checkers, runtime memory checkers, automated tests, all should be run on every check in. On a C# project I even created a tool that correlated diffs with a code coverage tool and rejected diffs that weren't covered by unit tests (it misses cases where code paths were executed by preexisting unit tests, so it didn't necessarily require a new test for every diff--I consider this a bug). But you always end up making compromises because there's Xthousand lines of code written at the beginning of the project that you don't have time to go back and write tests for. One of the reasons I'm really excited about Rust right now is that it makes it easier to set these things up at the beginning. A lot of memory checking you have to do with separate tools in C comes free with Rust's type system, while Cargo makes it very easy to get unit tests up and running. My hope is that if Rust finds wider usage, the projects I come into will be more likely to have been set up properly from square one, and it will be easier to work on larger code bases. I dunno, I'm somewhat new at technical leadership, so I'm still working out some of this stuff.
kelukelugames 12y ago
"copy and paste is the root of all evil."
superuser2 12y ago
>doesn't include the error handling that is constantly necessary in C I mean, I'm sure there are some cases, but how many C programs are capable of gracefully recovering from a malloc failure? Probably very few. If the program is going to crash anyway...
- ycombobreaker 12y ago
  ... best to do it deterministically and immediately! Easier to test, and no chance that an obscure preallocation leads to crashes elsewhere in the program.
- copsarebastards 12y ago
  I don't agree at all, but even if I did, that's only one of tons of cases. There are plenty of very recoverable errors which aren't handled by example code you copy off the internet, but which you really should be handling. Take networking code for example: do you really want to be dying without a visible reason because you didn't check `errno` and do a retry? This is really basic stuff.
- lawnchair_larry 12y ago
  It has nothing to do with being able to recover. It's about not continuing with unknown state.
deleted 12y ago
[deleted]

bentcorner 12y ago

> The biggest problem, I think, is that often you end up with 10 different ways to solve the same problem in the code because instead of looking at the existing code, people Googled for a solution with subtly different keywords than the previous person and found a different blogger. This kind of duplication is very hard to identify and remove, and this does cause bugs. It's interesting to code in large code bases. They end up getting to the point where no single person can ever understand the entire thing. It is usually at this point that things like Hungarian and strict coding guidelines really help. If you need an array of pointers to some kind of object, you can be reasonable certain that search will be able to find it.

woah 12y ago
IMO if your code base is large, you have already failed.
- copsarebastards 12y ago
  If your code base is large, you've failed as a coder. If your code base never gets large, you've failed as a company.
copsarebastards 12y ago
I think that sometimes Hungarian notation and strict coding guidelines can help, but more and more I think that there's no way to effectively enforce those things unless you automate them from the beginning. I've worked on very effective teams, where nothing ever got checked into master without two sets of eyes on it, strict rules were followed, etc., and there are always holes from lack of automation and legacy code. Automation helps: linters, static checkers, runtime memory checkers, automated tests, all should be run on every check in. On a C# project I even created a tool that correlated diffs with a code coverage tool and rejected diffs that weren't covered by unit tests (it misses cases where code paths were executed by preexisting unit tests, so it didn't necessarily require a new test for every diff--I consider this a bug). But you always end up making compromises because there's Xthousand lines of code written at the beginning of the project that you don't have time to go back and write tests for. One of the reasons I'm really excited about Rust right now is that it makes it easier to set these things up at the beginning. A lot of memory checking you have to do with separate tools in C comes free with Rust's type system, while Cargo makes it very easy to get unit tests up and running. My hope is that if Rust finds wider usage, the projects I come into will be more likely to have been set up properly from square one, and it will be easier to work on larger code bases. I dunno, I'm somewhat new at technical leadership, so I'm still working out some of this stuff.

kelukelugames 12y ago

"copy and paste is the root of all evil."

superuser2 12y ago

>doesn't include the error handling that is constantly necessary in C I mean, I'm sure there are some cases, but how many C programs are capable of gracefully recovering from a malloc failure? Probably very few. If the program is going to crash anyway...

ycombobreaker 12y ago
... best to do it deterministically and immediately! Easier to test, and no chance that an obscure preallocation leads to crashes elsewhere in the program.
copsarebastards 12y ago
I don't agree at all, but even if I did, that's only one of tons of cases. There are plenty of very recoverable errors which aren't handled by example code you copy off the internet, but which you really should be handling. Take networking code for example: do you really want to be dying without a visible reason because you didn't check `errno` and do a retry? This is really basic stuff.
lawnchair_larry 12y ago
It has nothing to do with being able to recover. It's about not continuing with unknown state.

deleted 12y ago

[deleted]