Do you split your code into libraries to avoid code duplication between projects?
Author
Hi,
I've had a set of core classes that I always use between projects for a while now, but as I make different projects it gets really tedious copying these around, and especially when they change (think bugfixes) and I want all projects to benefit.
My first thought in this case is to seperate some of those classes into a library. Is this a bad idea? What would you do?
I've made a common base folder where I put this code (categorized in subfolders). I added this folder as additional include folder in Visual Studio.
In my projects I add the code directly from that folder. Done.
I could compile libraries out of this (which would decrease compilation times). This would be preferrable if your code is mostly used in one configuration (plain non MFC, with MFC, one Visual Studio version). Since I need to jump a lot between VS versions (and also non VS) I rather include the code directly, have higher include times, but no library mismatches.
In my projects I add the code directly from that folder. Done.
I could compile libraries out of this (which would decrease compilation times). This would be preferrable if your code is mostly used in one configuration (plain non MFC, with MFC, one Visual Studio version). Since I need to jump a lot between VS versions (and also non VS) I rather include the code directly, have higher include times, but no library mismatches.
Well with Visual Studio, I normally have common code in a separate project, within the solution, which builds a lib.
The point of this is that I can use that project across multiple solutions. All the solutions link to the same common project so I don't need to copy the code but still always have the it easily available to me for bug fixes or to add features if needed. Giving me the best of both worlds.
I figured this was probably the way most people do things once they noticed that they could. [smile]
Edit: Ninja'd
The point of this is that I can use that project across multiple solutions. All the solutions link to the same common project so I don't need to copy the code but still always have the it easily available to me for bug fixes or to add features if needed. Giving me the best of both worlds.
I figured this was probably the way most people do things once they noticed that they could. [smile]
Edit: Ninja'd
Personally, this comes down to freedom of code modifications over the difficulty of hitting the ctrl-c/ctrl-v combo. The former always wins out.
Too often, I run into the situation where making a change to a module will break compatibility with older projects. This wastes time that I do not have so I'm generally against projects sharing code. I do keep a directory of common code, however that code must earn it's way in. I never make the assumption that code in a single project will be reused. I'll keep pasting it into projects until it seems ridiculous to do so. By that time, it's usually obsolete anyway.
I've worked with quite a few programmers that feel strongly that they must maintain some ideal of modularity. This is abused much more often than not. Most times, the KISS method prevails. Also, you're leaving your projects open to attack from the inescapable second rule of thermodynamics, thereby forcing yourself to spend more time fighting entropy than finishing projects.
Too often, I run into the situation where making a change to a module will break compatibility with older projects. This wastes time that I do not have so I'm generally against projects sharing code. I do keep a directory of common code, however that code must earn it's way in. I never make the assumption that code in a single project will be reused. I'll keep pasting it into projects until it seems ridiculous to do so. By that time, it's usually obsolete anyway.
I've worked with quite a few programmers that feel strongly that they must maintain some ideal of modularity. This is abused much more often than not. Most times, the KISS method prevails. Also, you're leaving your projects open to attack from the inescapable second rule of thermodynamics, thereby forcing yourself to spend more time fighting entropy than finishing projects.
My approach to this is quite simple. If I have completed something, I then identify re-use candidates within it based on what I'm doing next. If I havnt completed something, they I copy / paste the source files into a new, crude "branch" and then use it in this way.
Time spent sperating things into libraries just in case you need it somewhere else is time almost always wasted. You can do that step IF and WHEN you need that code.
Time spent sperating things into libraries just in case you need it somewhere else is time almost always wasted. You can do that step IF and WHEN you need that code.
I have divided all my commonly used functionality (everything from primitive data types to file i/o, generic data structures, image processing, polygon meshes etc.) into a hierarchy of small libraries and set the include and library paths to two common folders where I keep all the associated .h and .lib files respectively.
In that way I keep everything nicely separated and when I modify/update/optimize a library in the collection all I have to do is re-link it into the programs that use it -- all applications updated within minutes!
It takes some time to set up a system like this but it is definitely worth once you are done, in my opinion.
In that way I keep everything nicely separated and when I modify/update/optimize a library in the collection all I have to do is re-link it into the programs that use it -- all applications updated within minutes!
It takes some time to set up a system like this but it is definitely worth once you are done, in my opinion.
I started by having a common folder but this eventually evolved into a lib. Now, anyhting I find myself needing to copy and paste from another project is an ideal candidate to be added to the lib.
Murphy's Law of Code reuse: Every piece of code that is potentially reusable WILL eventually be reused.
Murphy's Law of Copy&Paste: Every change made to a single copy of a code snippet WILL eventually be needed in all copies.
This is what I do:
1. Put reusable code into separate files (separate classes/functions) whenever possible, and avoid crude copy&paste of code snippets at all costs.
2. When reusing code, which will potentially be modified in another project, I do "smart" copy&paste using the version control system.
This gives me the full benefit of copy&paste (I can modify "common" code in one project without breaking other projects), because it actually is copy&paste.
However, the VCS remembers that I have copied a file, and it will help me with reviewing and merging changes between different copies later.
Of course, when I have larger collections of reusable code (such as all of my vector and matrix classes and algorithms), I put it into a static library, or at least in a separate directory. This makes copy and merge operations easier.
Murphy's Law of Copy&Paste: Every change made to a single copy of a code snippet WILL eventually be needed in all copies.
This is what I do:
1. Put reusable code into separate files (separate classes/functions) whenever possible, and avoid crude copy&paste of code snippets at all costs.
2. When reusing code, which will potentially be modified in another project, I do "smart" copy&paste using the version control system.
This gives me the full benefit of copy&paste (I can modify "common" code in one project without breaking other projects), because it actually is copy&paste.
However, the VCS remembers that I have copied a file, and it will help me with reviewing and merging changes between different copies later.
Of course, when I have larger collections of reusable code (such as all of my vector and matrix classes and algorithms), I put it into a static library, or at least in a separate directory. This makes copy and merge operations easier.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement