Thread: Project folder maintanence

Originally Posted by Satya

how to track the changes i am doing in the code continuously? When should i approximately take the backup of my code?

Use a version control system.

Originally Posted by Satya

Suppose i have started working on a new project example C based project how should i maintain my folder structure? (...) Could someone please suggest me methods to properly maintain my project and if i visit my project say after one month how could i easily recognize the project file names.

Perhaps you should give us an example of what you are doing right now and what problems you are facing with it. You could also take a look at open source projects written in C for ideas.

first of all, use a version control system like git. apart from that, do what makes the most sense to you. but the generally accepted practice is to have source (C/CPP) files in one folder, often called "src," and header files in another folder, often called "include."

Using an automatic backup system (such as Dropbox) isn't a bad idea either to backup your changes between your commits to the version control system.

Originally Posted by Elkvis

first of all, use a version control system like git. apart from that, do what makes the most sense to you. but the generally accepted practice is to have source (C/CPP) files in one folder, often called "src," and header files in another folder, often called "include."

I've never seen any benefit to keeping headers in a separate folder.

Originally Posted by manasij7479

Easier to write install scripts?

This argument is often made. However, the need to install large numbers of header files is a sign of bad API design. You are leaking far too much internal detail if you are copying all of your headers as part of an installation.

It makes sense to keep externally-visible headers in a separate location but that vast majority of your headers shouldn't need to be in there.

However, the need to install large numbers of header files is a sign of bad API design. You are leaking far too much internal detail if you are copying all of your headers as part of an installation.

O_o

I see your generalization and raise you any C++ library heavily dependent on templates. Of course, I prefer all of my headers to be "bite sized" so even my C code uses a lot of external headers.

You can easily "leak" internal details, but the number of headers is unrelated to "bad API design". You could easily use GCC to "compress" all your headers into a single file, but that doesn't magic away bad design.

Soma

Originally Posted by phantomotap

You can easily "leak" internal details, but the number of headers is unrelated to "bad API design". You could easily use GCC to "compress" all your headers into a single file, but that doesn't magic away bad design.

Soma

It isn't directly about the number of headers. A project with two headers could suffer the same faults. The problem is the lack of proper design to separate the library API from its implementation details. Dumping all your headers in a single folder then shipping the entire thing is equivalent to just throwing your hands up.

As far as C++ template libraries, those are a messed up case that isn't really covered by what I just said. That's a language problem.

A project with two headers could suffer the same faults.

O_o

You've correctly identified my point.

Soma