Use class forward declaration where possible (Is this what you mean by prototyping?)

You can also use precompiled headers, or headers that include things that rarely change.

So after a while of programming, I realised that my code is becomming more messy and with slower compilation time.

Define "slower compilation time".

Two minutes? Five minutes? Twenty minutes? Ninety minutes?

As projects grow there is more to compile, which means it takes more time.

C++ uses a build model that hasn't changed much from the 1960's and 1970's. It generally requires every module to know details about other modules, and as you increase the number of modules the build time grows exponentially. Building a single .cpp file can cause a compiler to open hundreds or even thousands of header files.

Many solutions solve different problems. But you haven't said what your actual problems are other than 'slow build times'.

There are many books on build systems out there. Techniques depend on the actual problems you are having. The PImpl idiom and programming against interfaces reduce coupling between modules and forcing rebuilds based on dependency changes. The concept of a "unity build", essentially having only one extremely large compilation unit, helps keep the compiler from re-opening files. Lower optimization levels can reduce compiling time because some optimizations are incredibly time consuming. Template use and template meta-programming can cause build times to skyrocket because the programmer is willingly replacing runtime processing with build time processing. Distributed builds can share the work between machines. Each of those are solutions to different problems.

Without knowing what your actual problems are, we can blindly offer suggestions but they may not help.

So, while all the suggestions are fine, they don't usually solve the larger issues. Don't get me wrong, I've seen trivial missing references cause massive performance degradation, in fact, for fun:

class ThingGrid
{
public:
  typedef uint32_t                     Thing;
  typedef std::vector< Thing >  ThingArray_t;
 
  const ThingArray_t    operator[]( size_t y ) const    {return mThings[ y ];}
  const Thing               GetThing( size_t x, size_t y ) const   {return mThings[ y ][ x ];}
 
private:
  std::vector< ThingArray_t >  mThings;
};

It is a silly piece of code and obviously just an example, but it works as intended and if we were not talking about optimizations (and this were in say a JavaDoc commented header) it would not jump out as to why the above is really bad. If you didn't catch it immediately, yes returning the uint32_t "Thing" by value is intended but the return of the array is bad since it is also by value, so GetThing is massively slower than it should be thanks to a hidden temporary being made. Of course, fix the reference and things are all better, or are they? Take the following:

for( int x=0; x<things.Width(); ++x )
  for( int y=0; y<things.Height(); ++y )
    {ThingGrid::Thing thing = things.GetThing( x, y ); ... do something ...}

That piece of code is going to perform horribly on multiple levels even with the fix for the reference. Why? Think about it, there are 2 primary problems with that loop as applied to the given class.

[spoiler]

1. First problem is the inner loop iterates on Y while the data is laid out in an sub arrays of x indexed data. So, you are touching new chunks of memory each loop. Fix:

for( int y=0; y<things.Height(); ++y )
  for( int x=0; x<things.Width(); ++x )
    {ThingGrid::Thing thing = things.GetThing( x, y ); ... do something ...}

2. Even with that fix, you still get bit by the fact that as individual std::vectors each one points to different chunks of memory, so each time you complete an x loop you are likely blowing the cache and looking at a completely new chunk of memory. Fixing this means removing the inner vectors and using a single vector with manual y offset to indexing. Of course at that point, you could just use "for( const Thing& : mThings ) {}" and not have two indexes being maintained.

[/spoiler]

So, all said and done, while the simple rules of thumb items are important, I believe knowing your libraries and memory access patterns are much more important to prevent simple things like the above from being constantly adding up performance drains.

1. Preprocessing macros will significantly slow your compilation.
2. Do not include unnecessary header files.
3. Create a build target for speed emphasized compiler settings and work with that as you develop instead of what you usually use (probably a debug build). You can always make use of a debug build when you need to debug.

Compile time tip:

In a header file that doesn't use pointer as members, don't include the header file of the member object, instead do this:

B.h

#ifndef B_H
#define B_H

class A;

class B
{

public:

B();

private:

A* m_a;

}; 

#endif 

B.cpp

#include "A.h"

B::B
{
a = new A();
a->Initialize();
}