How do you structure your code/development environment ?
-
We all have common modules/classes/includes that we use in various projects, but people structure their code differently. For example, you could: 1) Have folders called Include and Modules, which contain the common code and then add search paths to your development environment so they get picked up. 2) Like (1), but for every project you copy over the includes/modules you require to the project folder (eg. Common\Include, Common\Modules, or just Common), and then use these copies. (1) has the advantage that any fixes/changes made to the includes/modules are immediately propogated to the projects that use them, without the need for any other work. The downside is that one of these fixes/changes may break a project (eg. due to it relying on certain behaviour) (2) has the inverse of the pros and cons of (1). Are there any other ways of working that you use ? Which model do you follow, and why ?
-
We all have common modules/classes/includes that we use in various projects, but people structure their code differently. For example, you could: 1) Have folders called Include and Modules, which contain the common code and then add search paths to your development environment so they get picked up. 2) Like (1), but for every project you copy over the includes/modules you require to the project folder (eg. Common\Include, Common\Modules, or just Common), and then use these copies. (1) has the advantage that any fixes/changes made to the includes/modules are immediately propogated to the projects that use them, without the need for any other work. The downside is that one of these fixes/changes may break a project (eg. due to it relying on certain behaviour) (2) has the inverse of the pros and cons of (1). Are there any other ways of working that you use ? Which model do you follow, and why ?
My opinion is: Don't copy header files - that's evil. Reference them.
-
My opinion is: Don't copy header files - that's evil. Reference them.
What about modules/classes ?
-
We all have common modules/classes/includes that we use in various projects, but people structure their code differently. For example, you could: 1) Have folders called Include and Modules, which contain the common code and then add search paths to your development environment so they get picked up. 2) Like (1), but for every project you copy over the includes/modules you require to the project folder (eg. Common\Include, Common\Modules, or just Common), and then use these copies. (1) has the advantage that any fixes/changes made to the includes/modules are immediately propogated to the projects that use them, without the need for any other work. The downside is that one of these fixes/changes may break a project (eg. due to it relying on certain behaviour) (2) has the inverse of the pros and cons of (1). Are there any other ways of working that you use ? Which model do you follow, and why ?
I'll go for (1) i.e. refer the common header files rather than making a copy of it and use. Because, as you said, if you copy the files, you could avoid crashes or compilation errors during development. But infact you are not avoid it but simply accumulating. All the compilation errors and crash will popup once you start to integrate will the latest common and you'll be in real trouble in sorting out the bugs. So better refer the common modules and incase of any trouble in latest common source, just get the old version from your version control and work with it until the guys fixes the latest common. :rolleyes: Regards, Jijo.
_____________________________________________________ http://weseetips.com[^] Visual C++ tips and tricks. Updated daily.
-
What about modules/classes ?
I design my projects so that lower-level, possibly common, modules go into separate DLL projects. Architecture's the name of the game...