Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Our project consists of user application and server application. The server application prepares data files that the user application consumes. Because the data is huge, it is stored in custom format. So the project includes many classes related to reading and writing the data. The user application does not need the writing side, so we don't want to have the code there both because it might run on resource-limited devices and because it prolongs compilation (C++ is not known for having fast compilers).

So say I have two classes (I have tens of such pairs):

  • DataReader
  • DataWriter

These classes both operate on the same thing, the serialized data. But the first is only needed in the user application and the second is only needed in the server application. Would you suggest keeping such classes

  • Together; in say
    • common/data/DataReader
    • common/data/DataWriter
  • Separate like
    • userapp/data/DataReader
    • serverapp/data/DataWriter

With this goes the compilation. The common stuff lives in common and is compiled into a library linked to both. So the first option further splits into two:

  • Together in common/data and linked to common.a or
  • Together in common/data directory, but each linked to the target that needs it.

Now each has it's advantages and disadvantages:

  • They are closely related, so it makes sense to keep them together. But
    • having both in one library makes that library larger and compile longer
    • compiling each separately means directory layout does not correspond to project layout, which is rather confusing and complicates the build scripts
  • Keeping them separate makes the build structure more logical and avoids unnecessary work for the compiler, but when updating them, components far apart need to be modified (both applications are maintained by the same team, so it's not like someone wouldn't be aware of the other part)

We currently have mixture between the approaches (some classes are separate, others not and the common library contains a lot of stuff that should be in the individual projects), which I would like to clean up.

Is there any usual recommendation for such situation? Or some useful experience with similar cases?

share|improve this question

Keep them together: any format changes will require editing them together, and unit testing the format is easiest done using your existing reader & writer code together.

However, just because the source files are stored together, doesn't mean they have to compile compile together. You could set it up so that (UNIX filename conventions for illustration only):

userapp depends on libreader.a depends on DataReader.o


serverapp depends on libwriter.a depends on DataWriter.o

and then there's no reason to build libwriter at all when you're only compiling the client.

share|improve this answer
... and the common/data/CMakeLists.txt is a mess with this file goes here and that file goes there and in Visual Studio (nor most other IDEs) the files don't appear together anyway. – Jan Hudec Nov 30 '12 at 14:12
If you have a particular build system and IDE in mind, perhaps you could add that to the question. Can it really not handle dependencies cleanly? – Useless Nov 30 '12 at 17:40
Most IDEs out there (Eclipse being exception) organize files by project they are included in, not by directory layout. So the fact that the files are in the same directory won't put them close together in the IDE. – Jan Hudec Dec 3 '12 at 7:53

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.