For bonus points - add robust code folding to this, especially when the folding persists across edit sessions.
I worked on a large embedded system where all the principal developers used such an editor (there was some occam heritage). One incautious copy and paste of 'a handful' of lines, and you had accidentally replicated a complete subsystem! It made debugging 'interesting'.
Every time I think 'Oooh - code folding - what a great idea', I retrieve those memories.
More generally, any time editor cleverness is interposed between the creative idea and the source code, I get a twitch. It should be possible to work on the source code without requiring anything more than a bare-bones editor - that is all I can assume about what my favourite editor shares with whatever future developers (incl. myself) happen to be using.
Yes, that's why in my previous job I simply forced all my team to use Vim, with almost the same vimrc. Before me, some were using Eclipse, jedit, even dreamweaver, that was a mess, also with encodings.
But to complete Jacques' rant, I'd say that if duplication is bad in the part of the code handling logic and actions, it is not bad and often "normal", or even "better" in configuration parts or in content parts (eg templates). Factorizing a list of configs to replace some duplication with logic (loops, conds) can be a very bad idea.
> Think about that ctrl-C, ctrl-V sequence next time you are about to use it.
Many people use "cut and paste" as a generic term that refers to either copy and paste or cut and paste. You have to figure out which they really mean from the context.
Great article. Code expands to fully use all available editing tools. If you can see 1000 lines of code on your screen at once, you'll work with 1000 line chunks of code. If you have great tab-completion, you'll make your APIs big enough to make the tab completion useful. If you get a million lines of boilerplate every time you create a file, every file will be more than a million lines long.
What's great about ed is that you keep most of the program in your mind. There is no tab completion. There is your brain. And when you keep the whole program in your brain, you write less code and the code you write is better thought out. I wish we could go back to the days of ed, but all we can do now is consciously resist the desire to work at our tools' maximum capacity.
Then came the full screen editors. They were a bliss compared to line editors. Really. If you don't believe me try 'edlin' for a day or so. We'll see how you like that. Then you'll be wondering how come any software got written at all for the first 2 decades of computing.
I have been wondering that, actually.
On the topic of the article, luckily, the Rails community (and python, and others) seem to have embraced this idea, under the heading "DRY principle" (Don't Repeat Yourself). There might be a connection between that embrace of DRY and the fact that Ruby/Python afficionados tend to prefer "simpler" text editors (Textmate, Vim, Emacs, Sublime) rather than IDEs.
Worth noting though that this can go too far the other way. I've definitely written things where, in my refusal to repeat myself, I've made a hard-to-read mess.
Here's an example from when I was very first starting out with ruby:
This is a pretty hard to read piece of code, despite my rambling comments. All done to avoid copying and pasting the same easy-to-follow method ~10 times.
Although I'm not from the punch card era, I overall agree with the sentiment of this article. I learned to code has a hobby when I was a kid and then took a CS degree. During the CS degree I was indoctrinated out of "bad habits" that I developed as a self-taught programmer. One of these bad habits was being terse. I took my degree during the golden age of createFactoryOfServerProcessGenerators() type things. Now, with more experience and wisdom, I realize I was right all along. A development environment that comfortably fits in your brain makes programming more effective and fun. And maybe I'm too idealistic, but I strongly believe the two are related.
Copy-and-paste is bad, I agree, but on the other hand, I hate it. And by 'it' I mean all of it. I have never seen a large system that could, for more than a moment in time, be seen as anything else than elephantiasis.
It's shameful and I'm sick of it. I want out. Right now, I'm paid quite well as a contractor to make some enhancements to a project developed by a hundred underpaid developers in a distant land, who did a remarkable job, considering. But it's rat's nest -- they didn't stand a chance. And I can't look myself in the mirror anymore and say this is what I do. It's grotesque. I'd rather run a coffee shop (and indeed I've been talking about it) because at least I could go home at the end of the day having seen a little beauty here and there, instead spending all day staring into the face of the Elephant Man.
I recently stumbled on them. Especially the second one has some entries that are very inspiring if you are feeling burned out / largely incontent with programming.
As usual, there is merit to the opposite side too. Don't create some huge abstraction with class hierarchies and virtual methods and stuff, just to avoid cutting and pasting a ten-line function somewhere.
Often it's a good idea to start by cutting and pasting, and then afterwards figure out what ended up being sharable.
Agreed. I recall a useful rule-of-thumb that states you should wait until the third time you need a bit of code before packaging it into something reusable. Otherwise, you might be wasting your time.
You're positing a false choice; it's not either-or. The proper abstraction for a cut-and-pasted 10-line function is generally an 11-12 line function, with just enough extra complexity (i.e. an extra argument or two) to capture the differences in the two implementations.
The huge abstraction with class hierarchies is an entirely different kind of idiocy. It's orthogonal to this problem. You can (and I've seen it done) cut and paste giant class hierarchies too.
I really disagree with the premise of the article that IDEs encourage copy&paste. Full screen editors do. IDEs do the opposite, by making it super-easy to reuse existing code through code completion and docblock tooltips. In a decent IDE, copy&paste is often more work than finding the right method and calling it.
My first programs ran on a programmable calculator. I wish I could have kept the habits I had back then. Drawing block schemata on paper before coding seemed tedious but it was in fact valuable. Damn you lord Sinclair and your ZX Spectrum for providing a full screen "editor" which let me skip the design phase. And it didn't really have cut'n'paste in the modern sense.
I'm not sure the original ZX Spectrum editor qualifies as "full screen" as selecting a line and visually editing that line are separate tasks. It has more in common with RegEdit than with Notepad.
Does anyone know if there are tools out there that look at a code base and find "similar" snippets of code?
I would expect such a tool to parse the language into AST form and find branches that are the same except some identifiers and a few other details. It is probably intractable in general, but I think it is feasible for most code bases.
Yep; we've just had exactly this problem with a contractor. Some functionality needed tweaking, which was done on one page - but on testing we found the exact same functionality hadn't been tweaked on all the other pages.
Huh?
Turned out it was a copy/paste job... which in turn became only the start of the rabbit hole. :)
It's gratifying to get something up and running quickly. I do a lot of "copy and paste programming" to get a functional prototype doing stuff. it's helpful when I need to show a non-technical person (e.g. my boss) in a convincing way. ctrl-c + ctrl-v is my best friend
Most of it is throw-away code: just playing with ideas and different implementations. Exploratory programming is cheap these days, and I really think it's for the better.
If it looks like I'm narrowing down on something I'm actually gonna use, I refactor, rewrite, simplify, and delete a lot of code. ctrl-x becomes my new best friend. (I write in natural languages much the same way.)
I understand the analogy, but on the other hand, the barrier to using a gun for killing people is nearly infinitely higher (I hope) than the barrier to using copy & paste to "just fix this little thing here".
So many times, when you need a quick solution for a small problem and you know that you have fixed this exact same problem a few weeks/months ago at a different spot, there's a huge temptation to just go and copy&paste those lines.
By doing so, you have just created debt. What if that code is using some API that you want to change a few years later? Whoever is going through the old code now has to fix up all instances of your copy & paste action.
What if the initial code contained a bug that somebody else fixed? They might not know about the copy pasta. It's very likely that they only fix the initial instance of the code and not all other places where it was pasted to, so the bug partially remains, or, worse, is later classified as a regression (which it's not).
So, coming back to your analogy, hating copy & paste is analogous for hating guns not only for their potential of killing people but also for their potential for causing accidents and for their potential to use them for any kind of potentially non-violent crime.
As the guy who is usually doing the refactorings to our 7 year old codebase, I'm the guy who is suffering from copy pasta and I'm telling you: I totally agree with the original article. I've yet to see a single instance where copy & paste of more than a single line of code didn't cause me non-insignificant amounts of additional work.
There are some greate advice however its impractical in the real world. (I am not defending copy and paste, the DRY principle should be your number one rule.) Most (good) contractors work in this way however its impossible to lay out your solution to its entirety and build a beautiful solution. Without specs being changed on you or you realizing that what you are building is not something the clint wants.
What he really hates is his lack of willpower when it comes to doing things the wrong way. Cut-and-paste enabled him to be lazy, but it certainly didn't force him to be.
[+] [-] samlittlewood|14 years ago|reply
I worked on a large embedded system where all the principal developers used such an editor (there was some occam heritage). One incautious copy and paste of 'a handful' of lines, and you had accidentally replicated a complete subsystem! It made debugging 'interesting'.
Every time I think 'Oooh - code folding - what a great idea', I retrieve those memories.
More generally, any time editor cleverness is interposed between the creative idea and the source code, I get a twitch. It should be possible to work on the source code without requiring anything more than a bare-bones editor - that is all I can assume about what my favourite editor shares with whatever future developers (incl. myself) happen to be using.
[+] [-] gbog|14 years ago|reply
But to complete Jacques' rant, I'd say that if duplication is bad in the part of the code handling logic and actions, it is not bad and often "normal", or even "better" in configuration parts or in content parts (eg templates). Factorizing a list of configs to replace some duplication with logic (loops, conds) can be a very bad idea.
[+] [-] markokocic|14 years ago|reply
Problem is copy-and-paste, which litters codebase with duplication and lead to messy and hard to maintain code.
[+] [-] Stratoscope|14 years ago|reply
> Think about that ctrl-C, ctrl-V sequence next time you are about to use it.
Many people use "cut and paste" as a generic term that refers to either copy and paste or cut and paste. You have to figure out which they really mean from the context.
[+] [-] frobozz|14 years ago|reply
I currently hate an application that I'm likely to end up working on that was authored with a generous helping of copy-paste.
[+] [-] jrockway|14 years ago|reply
What's great about ed is that you keep most of the program in your mind. There is no tab completion. There is your brain. And when you keep the whole program in your brain, you write less code and the code you write is better thought out. I wish we could go back to the days of ed, but all we can do now is consciously resist the desire to work at our tools' maximum capacity.
[+] [-] Autre|14 years ago|reply
[+] [-] swombat|14 years ago|reply
I have been wondering that, actually.
On the topic of the article, luckily, the Rails community (and python, and others) seem to have embraced this idea, under the heading "DRY principle" (Don't Repeat Yourself). There might be a connection between that embrace of DRY and the fact that Ruby/Python afficionados tend to prefer "simpler" text editors (Textmate, Vim, Emacs, Sublime) rather than IDEs.
[+] [-] mhd|14 years ago|reply
[+] [-] robomc|14 years ago|reply
Here's an example from when I was very first starting out with ruby:
http://pastie.org/2749772
This is a pretty hard to read piece of code, despite my rambling comments. All done to avoid copying and pasting the same easy-to-follow method ~10 times.
[+] [-] TelmoMenezes|14 years ago|reply
[+] [-] david927|14 years ago|reply
It's shameful and I'm sick of it. I want out. Right now, I'm paid quite well as a contractor to make some enhancements to a project developed by a hundred underpaid developers in a distant land, who did a remarkable job, considering. But it's rat's nest -- they didn't stand a chance. And I can't look myself in the mirror anymore and say this is what I do. It's grotesque. I'd rather run a coffee shop (and indeed I've been talking about it) because at least I could go home at the end of the day having seen a little beauty here and there, instead spending all day staring into the face of the Elephant Man.
[+] [-] 0x12|14 years ago|reply
[+] [-] MortenK|14 years ago|reply
http://c2.com/cgi/wiki?BurnOut http://c2.com/cgi/wiki?GetaLife http://c2.com/cgi/wiki?JustLeave
I recently stumbled on them. Especially the second one has some entries that are very inspiring if you are feeling burned out / largely incontent with programming.
[+] [-] ssp|14 years ago|reply
Often it's a good idea to start by cutting and pasting, and then afterwards figure out what ended up being sharable.
[+] [-] harto|14 years ago|reply
[+] [-] ajross|14 years ago|reply
The huge abstraction with class hierarchies is an entirely different kind of idiocy. It's orthogonal to this problem. You can (and I've seen it done) cut and paste giant class hierarchies too.
[+] [-] staktrace|14 years ago|reply
[+] [-] zerostar07|14 years ago|reply
[+] [-] skrebbel|14 years ago|reply
[+] [-] AndrewDucker|14 years ago|reply
[+] [-] praptak|14 years ago|reply
(Edited) Also: http://clonedigger.sourceforge.net/ Use it for great good.
[+] [-] finnw|14 years ago|reply
[+] [-] mjschultz|14 years ago|reply
I would expect such a tool to parse the language into AST form and find branches that are the same except some identifiers and a few other details. It is probably intractable in general, but I think it is feasible for most code bases.
[+] [-] ErrantX|14 years ago|reply
Huh?
Turned out it was a copy/paste job... which in turn became only the start of the rabbit hole. :)
[+] [-] mebassett|14 years ago|reply
Most of it is throw-away code: just playing with ideas and different implementations. Exploratory programming is cheap these days, and I really think it's for the better.
If it looks like I'm narrowing down on something I'm actually gonna use, I refactor, rewrite, simplify, and delete a lot of code. ctrl-x becomes my new best friend. (I write in natural languages much the same way.)
[+] [-] chaosfox|14 years ago|reply
[+] [-] pilif|14 years ago|reply
So many times, when you need a quick solution for a small problem and you know that you have fixed this exact same problem a few weeks/months ago at a different spot, there's a huge temptation to just go and copy&paste those lines.
By doing so, you have just created debt. What if that code is using some API that you want to change a few years later? Whoever is going through the old code now has to fix up all instances of your copy & paste action.
What if the initial code contained a bug that somebody else fixed? They might not know about the copy pasta. It's very likely that they only fix the initial instance of the code and not all other places where it was pasted to, so the bug partially remains, or, worse, is later classified as a regression (which it's not).
So, coming back to your analogy, hating copy & paste is analogous for hating guns not only for their potential of killing people but also for their potential for causing accidents and for their potential to use them for any kind of potentially non-violent crime.
As the guy who is usually doing the refactorings to our 7 year old codebase, I'm the guy who is suffering from copy pasta and I'm telling you: I totally agree with the original article. I've yet to see a single instance where copy & paste of more than a single line of code didn't cause me non-insignificant amounts of additional work.
[+] [-] klklklk|14 years ago|reply
[+] [-] rayhano|14 years ago|reply
[+] [-] becomevocal|14 years ago|reply
To get code shipped I usually copy and paste if it really saves me time, but make a checklist of optimizations I can do at a later date.
When that time comes, find/replace does the dirty work.
[+] [-] kleiba|14 years ago|reply
[+] [-] sylvanaar|14 years ago|reply
[+] [-] wccrawford|14 years ago|reply
What he really hates is his lack of willpower when it comes to doing things the wrong way. Cut-and-paste enabled him to be lazy, but it certainly didn't force him to be.
[+] [-] icebraining|14 years ago|reply
But like any sharp tool it has the ability to cut you just as easily as it cuts the wood, so you need to apply it with care.