Fabian Cenedese wrote:
Splitting C files is different to splitting C++ files or splitting Java files,
Fortran, Ada, ObjC, ....
In the case of C++, you can just put each method of a class in a separate .C file. Provided they all include a .H file which defines the class prototype it's ok.
The problem may not be the .cpp but the .h files. If I add a new member
or method all files of this class need to be rebuilt. With the independent
functions in C this may be easier to do. But still, if everything is rebuilt
then it doesn't matter how many files you spread your code over.
Of course from maintenance point of view splitting files is good though
I maybe wouldn't go down to function level, more like class level.
Otherwise the bad overview in the file is just transferred to the project
level.
That's no different than in C where you change a struct, union, or enum
(or other macros).
But most of your re-compiles will be after changing code not definitions
or prototypes. And even if it didn't save compile time [which it will]
it still makes code more maintainable.
As I said in my first post on the subject, there is no "hard set" rule
about when to refactor. If your class has 3 methods and is 75 lines of
code, it's probably better to have it all organized in one unit/file.
But if your class has 15 methods, and requires 1500 lines of code,
you're probably better off refactoring it.
Libraries are different from applications in this sense. In a library,
it usually makes sense to factor at the function level as you get a
better chance to smart link (as well as the other development
benefits). This doesn't strictly apply to C++ I suppose (well it may if
nothing calls a method), but it definitely does to C.
Tom
