Pitfalls of cut and paste coding

[Nightwalker83]

Hi,

I received this in email from code project:

We’ve all been guilty of it in our development careers at one time or another. When starting out using a language or framework that you’ve never used before you often have no choice but to. What I’m talking about is the act of “copy paste coding”, and it’s as common in the programming world as chewing gum under seats. When you copy and paste other developer’s code into your application it’s important to fully understand what the code does before you continue; or risk joining the many fools that have gone before you.

Read more here


That just goes to show you still need some understanding of how things work in order to avoid the same mistakes that were in the original code.


Nightwalker

[jmcilhinney]

Funny story. Make sure you mouse over the Ninja logo while you're there.

[FunkyDexter]

Euch, I hate cut and paste programmers. It's interesting to see that this story is about cutting and pasting from the internet whereas my experience of C&P has mostly come from developers cribbing each other's code "in house" - which is worse because all they really needed to do was get up and talk to the original programmer to gain some understanding.

The other guy I hate is the one who "fixes" your code without bothering to understand it first.

[Nightwalker83]

The other guy I hate is the one who "fixes" your code without bothering to understand it first.

It would probably help if the original coder bothered to document their project with comments.

[techgnome]

The other guy I hate is the one who "fixes" your code without bothering to understand it first.

It would probably help if the original coder bothered to document their project with comments.

It doesn't matter... I've seen fully commented/documented code "fixed" ... I've also seen fully commented/documented code that didn't do what the comments/documentation says it does...

That story is exactly why sometimes I try to avoid posting code on here - I do make a few exceptions depending on the circumstances - and sometimes when I do post code... depending on the situation, I'll sabotage it with some intentional bugs to prevent copy/paste. It forces them at least to look at the code an discover why they have a bunch of red & possibly blue squiggles.

I said it in a different post a little while back: Give a developer code, they'll be productive for 15 minutes... teach them how to code and they can build a career.

-tg

[techgnome]

Oh dear... it's not even 8:30 eastern, and there's the first copy sans understanding of the day.... If I could, I'd go back to bed.

-tg

[Nightwalker83]

It doesn't matter... I've seen fully commented/documented code "fixed" ... I've also seen fully commented/documented code that didn't do what the comments/documentation says it does...

People such as those should not be coding if they do such as poor job that later on down the track they have forgotten or somebody else updating the code can not figure out how it is suppose to work.

[dilettante]

If we start listing reasons why people shouldn't be writing code pretty soon we'll all be disqualified. All the same it is often tempting to respond to some questions by suggesting they hire a programmer.

Most of the stuff in the CodeBank forums here and at code-handout sites can't be applied blindly. Those samples and snippets don't always get updated with debugged versions and may need adjustment to suit different conditions anyway. I try to look at them as starting points or signposts rather than destinations. This improves my attitude a lot about warts on sample code.

[Nightwalker83]

If we start listing reasons why people shouldn't be writing code pretty soon we'll all be disqualified. All the same it is often tempting to respond to some questions by suggesting they hire a programmer.

Yeah, I just wish it was easier than having to spend ages trying to understand how a project is suppose to work before you attempt to upgrade it.

[dilettante]

Yeah, I just wish it was easier than having to spend ages trying to understand how a project is suppose to work before you attempt to upgrade it.

That's why you get the big bucks!

[Niya]

Yeah, I just wish it was easier than having to spend ages trying to understand how a project is suppose to work before you attempt to upgrade it.

If it were so easy then every moron who's idea of being tech savvy is being able to change fonts in a word document would be doing it, which would drive the price of the talent down which means programmers would get paid less.

[FunkyDexter]

It would probably help if the original coder bothered to document their project with comments.

Pah, comments are for the weak!

I'm being facetious but, actually, I think there's a serious point to be made: I think over-commenting is as bad as under commenting. When I see things like this:-

'Open the connection
Connection.Open

it makes me want to scream. The code in that case was self commenting and the developers comment is just noise.

Good variable and procedure naming also removes the need for a lot of noisy comments. I also hate this:-

public function Add(int X, int Y)
'Purpose: To add two integers together
'Scope: This function is publicly available
'Developer: FunkyDexter
'Date: 9 10 2012
   return X + Y
End Function

Again, the code was self documenting and the comments are just noise. OK, maybe the developer and date comments are handy from an admin point of view. Also, I guess if you're using a tool that automatically reaps comments from your code to produce documentation then the other comments are useful purely to feed that (although I hate that aproach to documentation on principle - I think it misses the point of documentation) but don't stick that stuff in there and pretend you were trying to help out the next developer because you weren't. What you were doing was feeding an anally retentive compulsion.

Comments are for when the code isn't obvious. And there will be those times. Mostly they should describe domain context e.g.
'Apply a 25% uplift to category 5 orders because of the extra workload they entail
There are also time when you need to explain the use of a technology that's non-standard in the rest of the app.

Finally, they should NOT be used for this to excuse away a bad design decision in the vain hope that the next developer won't think you were a complete yutz. He'll think that anyway, it's in our nature to assume our predecesser was a pin-headed loon whether he was or not.

Comments are really important and that's why it's important to use them sensibly. Too much noise stops me from hearing the important stuff.

[techgnome]

Pah, comments are for the weak!

"Documentation, we don' need no stinkin' documentation. If it was hard to write, it should be hard to use."

I'm being facetious but, actually, I think there's a serious point to be made: I think over-commenting is as bad as under commenting. When I see things like this:-

'Open the connection
Connection.Open

it makes me want to scream. The code in that case was self commenting and the developers comment is just noise.

Yes and no... I do comments like that all the time... NOT because I'm documenting the code... but rather I'm documenting my steps BEFORE I write my code. I sometimes will find myself starting a sub, then immediately filling it with comments that layout the steps I need to perform as well as the logic. More often than not, the comments get left behind in the code... obvious or not.

Good variable and procedure naming also removes the need for a lot of noisy comments. I also hate this:-

public function Add(int X, int Y)
'Purpose: To add two integers together
'Scope: This function is publicly available
'Developer: FunkyDexter
'Date: 9 10 2012
   return X + Y
End Function

Again, the code was self documenting and the comments are just noise. OK, maybe the developer and date comments are handy from an admin point of view. Also, I guess if you're using a tool that automatically reaps comments from your code to produce documentation then the other comments are useful purely to feed that (although I hate that aproach to documentation on principle - I think it misses the point of documentation) but don't stick that stuff in there and pretend you were trying to help out the next developer because you weren't. What you were doing was feeding an anally retentive compulsion.

Generally, stuff like that is the stuff office standards are made of... in some cases it's a necessary evil to keep people in check.

Comments are for when the code isn't obvious. And there will be those times. Mostly they should describe domain context e.g.
'Apply a 25% uplift to category 5 orders because of the extra workload they entail
There are also time when you need to explain the use of a technology that's non-standard in the rest of the app.

Agreed... and for the most part, that's the general guideline I follow: Will I be able to understand this or remember why I did this in 6 months?

Finally, they should NOT be used for this to excuse away a bad design decision in the vain hope that the next developer won't think you were a complete yutz. He'll think that anyway, it's in our nature to assume our predecesser was a pin-headed loon whether he was or not.

Comments are really important and that's why it's important to use them sensibly. Too much noise stops me from hearing the important stuff.

-tg

[FunkyDexter]

I'm documenting my steps BEFORE I write my code

Yeah, I do that too, but I remove the comments again as I go. My argument isn't so much with putting those comments in, or even failing to take them back out again, it's with the dogmatic insertion of a comment before every line of code in the belief that the comment will be useful to the next developer.

stuff like that is the stuff office standards are made of

Agreed. In fact I think it's "standards" that are largely responsible for an awful lot of the redundant commenting I see. More than once I've come across a culture where the "function header" style of comment is mandatory and, when you start questioning why, it quickly becomes apparent that it's solely so the team has some standards to apply. They've long since accepted that coding style is extremely subjective and difficult to standardise but insisting on some arbitrary bit of commenting allows them to say "we have coding standards". But nobody ever stops to ask "are those standards serving a purpose".

Will I be able to understand this or remember why I did this in 6 months?

That's the test I use too. Mind you, it's alarming how often I find myself looking back at a comment and thinking "Did I understand that comment 6 months ago when I wrote it? Because I sure as hell don't now" I guess when a concept is complex enough to merit a comment it's usually too complex to be easily described.


And don't even get me started on the culture that dictates you must produces reams and reams of redundant documentation that's going to do nothing other than sit in cabinets growing cobwebs until the organisation collapses under it's own archiving costs. Documentation can be useful (e.g it documents an agreement with a customer), but if you're not using it you probably shouldn't have bothered creating it.

[Shaggy Hiker]

My comments are notes to my own future.