Pitfalls of cut and paste coding
Hi,
I received this in email from code project:
Quote:
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
Re: Pitfalls of cut and paste coding
Funny story. Make sure you mouse over the Ninja logo while you're there.
Re: Pitfalls of cut and paste coding
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.
Re: Pitfalls of cut and paste coding
Quote:
Originally Posted by
FunkyDexter
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.
Re: Pitfalls of cut and paste coding
Quote:
Originally Posted by
Nightwalker83
Quote:
Originally Posted by
FunkyDexter
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
Re: Pitfalls of cut and paste coding
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
Re: Pitfalls of cut and paste coding
Quote:
Originally Posted by
techgnome
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.
Re: Pitfalls of cut and paste coding
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.
Re: Pitfalls of cut and paste coding
Quote:
Originally Posted by
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.
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.
Re: Pitfalls of cut and paste coding
Quote:
Originally Posted by
Nightwalker83
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!
Re: Pitfalls of cut and paste coding
Quote:
Originally Posted by
Nightwalker83
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.
Re: Pitfalls of cut and paste coding
Quote:
It would probably help if the original coder bothered to document their project with comments.
Pah, comments are for the weak!:p
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:-
Code:
'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:-
Code:
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.
Re: Pitfalls of cut and paste coding
Quote:
Originally Posted by
FunkyDexter
Pah, comments are for the weak!:p
"Documentation, we don' need no stinkin' documentation. If it was hard to write, it should be hard to use."
Quote:
Originally Posted by
FunkyDexter
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:-
Code:
'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.
Quote:
Originally Posted by
FunkyDexter
Good variable and procedure naming also removes the need for a lot of noisy comments. I also hate this:-
Code:
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.
Quote:
Originally Posted by
FunkyDexter
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?
Quote:
Originally Posted by
FunkyDexter
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
Re: Pitfalls of cut and paste coding
Quote:
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.
Quote:
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".
Quote:
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":rolleyes: 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.
Re: Pitfalls of cut and paste coding
My comments are notes to my own future.
