# Should I write class functions in file header

This topic is 1982 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi

When I make a new class I create a new header file, give it the name of the class and paste this:
 #ifndef MYNEWCLASS_H #define MYNEWCLASS_H class MYNEWCLASS { public: MYNEWCLASS(/*Init prameters*/) { //init stuff } //Functions protected: //Variables }; #endif 

I proceed to fill in what I need.

Now, I create a new source file with the same name as the header and implement the functions:
 void MYNEWCLASS::MyFirstClassFunction(/*paramters*/) { //things goes here } 

What I really bothers me is how quickly all the files start piling up. I figured I might cut the number of files in half just by placing the class functions in the header files. I do realize that my files may get quite lengthy but once it is finished I don't have to touch it again.

What do you think?

##### Share on other sites
Lengthy files, whether changing or not, will be included every time you compile a file that includes that files. If you have code in a header files that doesn't have to be there, it will consume compile time for little or no benefit. Keep the content of your headers to a minimum to not pollute the file with stuff that the compiler doens't need to compile source files that needs the header.

Of course there is a limit where too many files may impact the linker stage instead. You should not necessarily separate each little class in its own header/source pair, but group functionality into a single pair if the individual components are small enough. But at least keep non-necessary code out of the header file.

##### Share on other sites
In addition to what Brother Bob said, if they do change (for example, a bug is found) and you make the change solely in the source file, only that source file needs to be recompiled. But if you make a change in the header file, every source file and header file that includes that header file has to be recompiled from scratch, as well as any source or header file that includes header files that includes the header that changed, and so on. It snowballs.

Adding even a single space to a header file that is included in many other header files can make recompilation as bad as doing a "Rebuild All".
But making changes to a source file isolates the compilation to just that file, allowing you to change the implementation (commonly kept in source files for exactly this reason) without compile-time penalties for the change, as long as you don't alter the interface (kept in the header files).

Further, keeping your header files clean and commented make them self-documenting. If I forget what a function or class does, I jump to the header file and view the interface. My code's interface (and the comments with them) is my documentation, and it's easy to access and read because it isn't cluttered up with thousands of lines of implementation details.

In fact, I don't want to know the implementation details, because I don't want to unintentionally depend on secret knowledge of the implementation - I only want to depend on the explicit promises of the interface.