Should we "balance" the amount of codes between .h and .cpp?

Question

As far as I know, .cpp usually contains far more codes than .h, mainly because .cpp contain implementation details of functions instead of just one line of class member/method definition.

Here comes to my mind is a quite weird idea: is it good practice to write or migrate some contents or codes from .cpp to .h, in order to reduce the amount of codes in .cpp?

I know we should not write everything in header in order to:

1. Prevent extra compile time when recompiling codes after content is changed in the header

2. Prevent include one header from another header which is not necessary for every compile unit (i.e.:prevent header spaghetti)

but I think some contents can be moved to header "safely", such as function documentation and functions that fulfilling all conditions below:

1. Rarely changed functions

2. Simple or trivial functions (e.g.:setters and getters)

3. Functions that does not lead to extra include statements in cpp

and the bonus advantage of moving functions to headers is we can declare those functions as inline which gains extra performance improvements.

Is it a good practice to narrow the line number difference between header and corresponding .cpp files?

Answer 1

There is no advantage in putting code in the headers just to balance the amount of code in headers and cpp files. Unless you find that aesthetically pleasing, I guess?

There are, however, a number of reasons for stuff to be in header files, mostly related to actually using said stuff in multiple compilation units. For example, if you want to allow the compiler to inline a function, or when you want to be able to use a template in multiple compilation units.

There are also very good reasons to avoid putting stuff in header files. Chief among those is that a change to a cpp file should only mean the recompilation of that cpp file (unless the interface has changed, but then you aren't changing only that file), while a change to a header file means the recompilation of all the files that directly or indirectly include it.

Answer 2

First, C++ (I mean at least C++11) is practically speaking slow to be compiled, in particular because the standard container library is mostly header-only code, and standard headers pull a lot of code (e.g. <vector> is pulling 10K lines on a recent Linux GCC 5!), and you'll better use standard containers quite often. A possible trick might be precompiled headers, but these have also disadvantages, and you practically need to have a single header (which is #include-ing a lot of system or library headers) to make that work well.

^{(if you have time -and you'll need a lot of it-, you might help the C++ standard committee -they do welcome constructive feedback- and contribute to C++ free software compilers like GCC or Clang/LLVM)}

Then (unless you systematically enable link-time optimizations -which slows down compilation time a lot, e.g. by at least a factor of two-, e.g compile and link with g++ -flto -O2 on a recent GCC), a header needs to contain those functions which you want to be inlined, and practically speaking in genuine C++11 code you have a lot of inlined functions.

Some people (including some standard C++ library implementors) are physically separating some "implementation" part of the header in a separate file (but #include-d by some public header file), mostly for readability reasons. For example, on my GCC 5 Linux, /usr/include/c++/5/bits/deque.tcc is indirectly included from <deque> (and other) header.

Future C++ standards might define some module mechanism (but not in C++17!)

Is it a good practice to narrow the line number difference between header and corresponding cpp files?

I am not a native English speaker, so I have hard time understanding what you really mean, but I guess that you are referring to have quite large header files (perhaps #include-ing some "implementation detail" headers). That is ok. In particular, templates practically need to be mostly implemented in header files.