Opinions regarding C++ programming practice

I have a program that I am writing, not too big. Apart from the main function, it has about 15 other functions that called for various tasks at various times. The code works just fine all in one file, and as it is right now.

However, I was wondering if anyone had any advice on whether it is smarter/more efficient/better programming to put those functions in a separate file different from where main is, or whether it even matters at all. If yes, why? If no, why not?

开发者_Go百科I am not new at C++, but definitely not an expert either, so if you think this question is stupid, feel free to tell me so.

Thanks for your time!

Depends on how big those functions are. If your source file starts to get over several hundred lines of code in length, there is reason to extract part of the functionality into one (or more) separate file(s).

If you can group the functions into distinct sets based on their responsibilities and/or their level of abstraction, you may prefer separating them into distinct physical files (and classes of course) along those lines. E.g. some functions may work with file I/O while others do some computation. Or some functions do low level bit flipping chores within file I/O, while others build on the former to implement some more abstract functionality.

Another reason to partition your code would be if some of the functions were used by more than one client, but this apparently does not apply to your case. (However, this is probably going to change if / as your app is further developed and extended in the future...)

It's good to separate your code into different files based on their similarity. You could break it up by class if you have multiple classes. If you have several functions that could be used in other programs, you should put them in their own file for portability.

Since you mentioned only functions, I assume your program is not object-oriented. If it were, I'd advice to have one class per .h/.cpp pair. In your case it depends on whether those functions can be grouped into 2 or more subsets. If so, I'd put related functions together in separated .cpp modules, and always having a corresponding .h header containing their prototypes.

Having all those 15 functions in the same module isn't necessarily correct or incorrect. Again, if they are all strongly related they should belong to the same module. Another rule to decide is the module size itself. I find hard to manage a module that has grown to more than 1000 lines, this threshold is a warning sign that it should be split. These two things are related, usually when the module gets this big it also probably has two or more distinct groups of functions.

Assuming that each function is pretty small then it doesn't make sense to split it between files, IMO.

If functions are several hundred lines of code then it might be better to split it out. Mainly because it make it easier if/when you extend the program.

I'm adept as using headers only classes wheenver it's possible. It's more efficient because compiler can perform more optimizations this way, cost is that compilation times are longer. But you'll have the same benefit is your program is fully contained in a single source file.

However if you intend to reuse your code it's sensible to split it between logical units. Systematic splitting between classes regardless of dependencies or logical unit could even be considered a bad practice (well, in some other languages like java, you have not much choice...).

I would say that if you end up needing to use Ctrl+F to find the function you're looking for, it's probably time to start breaking the file up.

Likewise, if you're needing to use Ctrl+F to find a certain piece of code within a long function, it's probably time to start separating it into multiple functions (or work on writing more concise code).

Bugs will be much more difficult to track down (and more time consuming to fix) if you're having to spend a lot of time spelunking through the code.

Whenever you're breaking up files or functions though, try to separate them in ways that make sense; and not just to you, but also to the average human being. Assuming that you're the only person that will look at your code is foolish. If you come back to the project after a few years of absence, you may very well be a different person than you are now.

One might assume that larger programs, such as those developed commercially, keep their code across more than one file. Can you imagine the size of that file! It is a good idea to extend such good practices even to small projects.

As far as the code is concerned though, it usually doesn't make any difference at all where the physical code is located, as it all ends up in the same place (your shared library/DLL or executable).

if you feel you will re-use some part of the code in some other application, then split that part into different files (headers and implementation).

Other than that, IMO, don't bother.

M.