When writing code, I always try to imagine how some other programmer would react when he's got my classes in front of him and needs to use them in his own code. The public interface (aka API) of all components has to be as intuitive and simple as possible. In larger projects, this other programmer can soon be you, when you don't remember the details anymore some weeks later ;)

Apart from that, finding good, rememberable terms for any concept and module of a project is very important. And the larger the project, the more components it should be breaken down to. Use multiple .dll/.so based components, namespaces to seperate the various units in code (like eg. "Math", "Audio", "Storage"), don't write one large "renderer" class, create 10 smaller ones which do the job. And keep your files organized, filename-wise and with multiple subdirectories, as my foreposter said.

-Markus-

It's pretty much unix standard to use one include/ and one source/ (or src/) directory so I use that. I use pretty much one file set (.h+.c++) per class, this is best in the long run as the classes grow you want it this way...

When we are several developers on a project (which we often are) we generally try to avoid editing the same files and make sure we check in files in the repository ("backup" system, check http://subversion.tigris.org for instance) in turn to not make files screwie.

For all *nix based platforms (right now linux and mac os X) we use Makefiles (with autoconf (configure scripts)) and windows we use whatever visual studio uses, I'm not familiar with the .net editor at all.

Binaries such as game data is never an issue, that usually works by itself since one artist is often working on one file at a time.

Make sure to design your project first, even the smallest things for hours of thinking sometimes, because then you will probably code smarter classes, which will be both modular and extendable. You will own that hours spent on designing many times over on a larger project.

Bah, just me ranting
Albert

Quote:Original post by Think128
Out of curiosity, why do people put extranious code in .cpp/.hpp pairs? Why not just in a .hpp file and leave it at that?

Two answers:
1) if you speak about having one file for the whole project:
lucky_monkey gave you a correct answer. Here is the figures: I have worked on a professionnal film scanner driver+software for the past 5 years. The directory tree contains 42 MB of source code. It is included in a more important project - a minilab management software (>160 MB). In the end, our source tree contains more than 200 MB.

That would be a rather big file :)

2) if you speak about avoiding using cpp files and use only hpp file:
C++ != java. hpp files are not compiled if they are not included in at least one cpp file (unless you specify really weird compiler options).
C++ uses a declare/define paradigm, which allow you to forward declare and define later. This is the primary reason for having the cpp/hpp duality.

Regards,