Is code reuse a lie?

Basu · 2009-07-14 03:30:37

So when we started learning about this called 'object oriented programming' back in high school, one of the virtues of 'modern' object oriented languages was that it allowed 'code reuse' -- ostensibly since your code was neatly packaged into clean, functional classes, you'd be able to move code straight from one project to another. In the years since then, I've found that it doesn't seem to work that way. I'm willing to believe that part of this is my own inexperience: I've probably rebuilt from scratch more projects than I shared code across.
However, there is a lot of code being shared out there, especially for scripting languages. CPAN is the first thing that comes to my mind and I use a bunch of third party libraries in a lot of my Python code. However I get the feeling that a lot of this is due to the loose nature of scripting code and the fact that much of this was specifically designed to be reused (as opposed to the carefree reuse that initial OO education led me to believe would happen).
Also having never worked in a corporate setting, so I can't say if there is any real reuse in a more disciplined setting. A quick Google search didn't turn up any published stats on corporate code reuse.
My question to the community: Is code reuse a lie? Or does it take place at a level higher than just individual classes (ie structured libraries)? Also do you know how reuse works in professional software shops?

Allan · 2009-07-14 03:33:54

I think you hit the nail on the head a bit there without realising it... code that can be reused in many ways tends to be provided in libraries. Unless you are working on a series of inter-related projects, the code you actually write probably will not be that reusable.

jwcxz · 2009-07-14 03:54:47

I completely agree... I don't think I've ever reused my code between projects. OO's definition of "reuse" falls more along the lines of instantiating objects to help reduce pure, literal redundancy.

One very interesting language to look at is VHDL (or another hardware description language). You create components, instantiate them from other larger components, and tie signals ("wires") between them to get them to interact with each other. It's a fascinating language because it brings some of the aspects of object-oriented languages over to really low-level stuff (FPGA programming in my case).

Edit: forgot where I was going with that... anyways, in the case of VHDL, it is difficult to always reuse components across different projects because timing is absolutely critical in FPGA design. But when it does work, things are absolutely beautiful. And that's a direct parallel to reusing OO code.

Last edited by jwcxz (2009-07-14 03:56:41)

sand_man · 2009-07-14 04:26:47

Yes well think about the Java API. That is full of reusable code isn't it?
It all depends on your own implementation. If you actually intend on reusing something in the future, you should design your classes with that in mind.

scj · 2009-07-14 04:48:06

It's one of those things that should work in theory but rarely do in practise. Properly abstracted classes do allow code reuse, but unless you are actually intending to write a library, it's easier to just to implement something that works.

fukawi2 · 2009-07-14 05:22:16

I thought code reuse was more talking about re-use within 1 application. (eg, using functions) so instead of having the same 10 lines of code over and over again, you'd have a function with those 10 lines and just call that function instead....

Of course this comment is from someone who's never had any formal training in programming

Last edited by fukawi2 (2009-07-14 05:22:40)

keenerd · 2009-07-14 06:09:14

I've never had code reuse with OOP. VHDL, sometimes, but I have not done any serious high performance FPGA work.

The real code reuse has happened with learning functional programming. I just now wrote a page of text introducing the concept, but it did not do FP any justice. This is easier to read:
http://www.defmacro.org/ramblings/fp.html

Just about everything gets simpler with more FP-style code in a project. I am no wizard at it, and I usually have a messy knot of imperative code remaining either near the core data structure, or on the edges of the user interface.

oib111 · 2009-07-14 06:44:11

I think the only class I've ever reused between projects was a simple class I made to help me use sockets in a simpler manner.

Zeist · 2009-07-14 06:50:16

I reuse some things every now and then, mostly stuff for passing data back and forth to the GPU for my cpu-gpu hybrid processing. Most other things that I reuse has made it into libraries though, so most of my code re-use comes from using libraries.

Last edited by Zeist (2009-07-14 06:50:37)

Trent · 2009-07-14 15:35:40

I think code reuse (in the sense usually applied to OOP) is less about copying and pasting code between projects, and more about using the same code in more than one context.

Imagine three classes A, B, C that share an interface. The status() method is the same for all three, but the serialize() method is different in each class. Without code reuse, you would copy identical code from A.status to B.status and C.status, which could be a problem if the code in A has a bug in it which becomes a serious problem in B or C. With OOP-style code reuse, you derive A, B, and C from an abstract class Z which contains an implementation of status() and a declaration of serialize(). Then each child "re-uses" the code in Z without having to write it in each class.

Furthermore, imagine that you derive class AA from A, and you need to modify the serialize() method ever so slightly. If most of the code is identical, you may be able to call A.serialize() from AA.serialize(), hence "re-using" the code in A.serialize() without copying it into AA. You might argue this is a redefinition of "reuse", but I think it is the generally accepted definition in OOP.

Aside from that... you learned about code reuse and OOP in high school? Surprising.

Basu · 2009-07-14 19:08:10

Thanks for all your input. I was thinking mostly in terms of using code from one project in another, but code reuse and Trent describes it now makes perfect sense in comparison. In this case, I think OO was largely a win (for the average developer). I'm still looking for industry stats on how code gets shared across project (or any war stories on the matter). I think a blog post will be coming.
Also, @Trent I went to high school in India where we had a rather advanced curriculum but a not-so-advanced teacher. But I still managed to skip the first CS class at college, so it turned out well enough.

HashBox · 2009-07-14 22:36:54

I can't say I've taken on many "big" projects, but I rarely find myself reusing code. As I learn and become more proficient, I find myself rewriting stuff in different and/or more efficient ways.

Code evolves over time. Your skills improve and you just end up doing some things differently.

Of course I reuse code in the "splitting code into functions" sense as any programmer should

Actually I lied, there are a couple of pieces of code I reuse, which are from an SDL/OpenGL app I wrote once. When I find myself diving into OpenGL I often take these pieces of code and use them as a starting point, but usually end up rewriting most of it in the process.

Aprz · 2009-07-15 02:09:52

Nah, I don't recall ever using my class outside of the project it was intended for. There were moments I found it very handy like if I wanted to create a game full of monsters, I'd make an abstract monster class, then have goblins, humans, rats, demons, and all that good stuff extended it. So then you would have players that could just do attack(Monster target), and I wouldn't have to overload the function a bizillion time for every monster I clicked on. Often, if I did try to reuse my code outside of the class, I would need to adjust it for the game, which if the monsters had the same feature as the previous game, well, it would work (very easy to override the function), but if I needed extra features or change something like the constructors or parameters, well, that would break the previous game. So I don't find it too useful for using outside of it's intended project.

Dusty · 2009-07-15 03:40:16

Code reuse is a decision.

Dusty

Dieter@be · 2009-07-15 16:53:22

Also, never use OOP "for the sake of it". only use it when it feels right. (just like rdbm's)

buttons · 2009-07-15 20:30:44

I reuse things all the time. But like Dusty is (I think) trying to imply, you have to do it consciously. Just any old function or class won't generalise to all projects. You have to write them that way.

Often that takes time, and programmers are pretty lazy in general. However, if I find it's something I use between projects, I will take the time to rewrite it in a general way and update both projects to interface to the new code.

Sometimes I write them that way from the beginning, but only when I can already envision several projects along the same lines. Someone already mentioned a hardware interface, which is definitely one of those times.

Napaim · 2009-07-16 18:01:54

I rarely reuse code apart from mathimatical routines I've written myself as a challenge for ProjectEuler or any other programming challenges!
It's rather good fun coming up with prime generating functions and improving on them time and time again as the need takes you.

rochus · 2009-07-19 09:01:15

Maybe you're doing "code reuse" just plainly wrong? Code Reuse does not mean that you package everything into an .so and reuse this one, because most functions don't seem to relate or are just too tiny and specific to be packed into one. Or, for example, you have some project specific code inside your classes.
So what? Take your code, strip out the project specific stuff, put it into a file and somewhere on your hdd, not into an .so that you have to manage - which often just sucks. Have a code library lying around somewhere and keep remembering which code you already wrote for something else, or which code comes near to something you use already somewhere else. For example, if you manage to properly strip the project specific stuff from a C++ class, try to make a template out of it (this is eaven easier in D, which has much improved templates over C++). If your language doesn't provide any means of templating, try to reduce the function/class/whatever to the most still-having-in...
When you've done this, don't put it in folders like ~/library/c, ~/library/python, ~/library/erlang but get rid of this language diversification. put it into ~/library/sockets ~/library/gui or ~/library/algorithm or something like this - or try to use a personal wiki...
Code Reuse in a non-project-way is not having a .so for each and every bit of code you write. It's more about managing your own source code that way that you know where your already written stuff is, organized by topic, not by language. If your solution is written in C, but you require it in python, than just port it, place the python solution back into your library and you're done. Of course, project-oriented, try to not reinvent the wheel for every bit, abstract...

I don't know about you, but for myself this way works really great. If you question my experience: Dozens of small projects and some huge, e.g. having about 1.8mio LoC.

regards.

PS: Managing this via folder structures doesn't feel quite right, yes. You should have the possibility of tagging, commenting and adding information to your code _not_ inside the source files... but as any of the desktop wiki or wiki-software doesn't feel right (e.g., I can't stand ZIM) and there's no good code management software out there, that's my current state of organizing my code.

PPS: In my opinion, the usage of code reuse is not passed properly in school, but the idea is somewhat: try to think in abstract ways to pack your problem into the most abstract base, to build less abstract solutions or project specific implementations from or around that abstract base. OOP is just one way to do this. If your project is one class where everything is stuffed in, you're doing OOP wrong, not code reuse. :>

Last edited by rochus (2009-07-19 09:07:21)

wuischke · 2009-07-19 09:09:00

Please have a look at Higher order perl. (Any good Lisp,Haskell,... book would do it, too, but Perl is probably easier to understand.)

Imho, the essence of code reuse is to identify the parts you are going to reuse, abstract them into a general case and re-use a specialization of this general case.

An easy example: How often did you find yourself writing a loop to iterate over an array? A "for each" construct will make this a lot easier and less code. That's already code reuse.

Basu · 2009-07-21 17:18:12

I put some of the things i learned from this thread into a blog post. Feel free to leave a comment and let me know if I missed something.

wuischke · 2009-07-21 17:26:01

A good write-up. I like your style, it's very comfortable to read. My compliments.

renners1 · 2009-07-24 01:51:48

I re-use code all the time.... ctrl-c and ctrl-v!!!

Arch Linux

#1 2009-07-14 03:30:37

Is code reuse a lie?

#2 2009-07-14 03:33:54

Re: Is code reuse a lie?

#3 2009-07-14 03:54:47

Re: Is code reuse a lie?

#4 2009-07-14 04:26:47

Re: Is code reuse a lie?

#5 2009-07-14 04:48:06

Re: Is code reuse a lie?

#6 2009-07-14 05:22:16

Re: Is code reuse a lie?

#7 2009-07-14 06:09:14

Re: Is code reuse a lie?

#8 2009-07-14 06:44:11

Re: Is code reuse a lie?

#9 2009-07-14 06:50:16

Re: Is code reuse a lie?

#10 2009-07-14 15:35:40

Re: Is code reuse a lie?

#11 2009-07-14 19:08:10

Re: Is code reuse a lie?

#12 2009-07-14 22:36:54

Re: Is code reuse a lie?

#13 2009-07-15 02:09:52

Re: Is code reuse a lie?

#14 2009-07-15 03:40:16

Re: Is code reuse a lie?

#15 2009-07-15 16:53:22

Re: Is code reuse a lie?

#16 2009-07-15 20:30:44

Re: Is code reuse a lie?

#17 2009-07-16 18:01:54

Re: Is code reuse a lie?

#18 2009-07-19 09:01:15

Re: Is code reuse a lie?

#19 2009-07-19 09:09:00

Re: Is code reuse a lie?

#20 2009-07-21 17:18:12

Re: Is code reuse a lie?

#21 2009-07-21 17:26:01

Re: Is code reuse a lie?

#22 2009-07-24 01:51:48

Re: Is code reuse a lie?

Board footer