About one class/function per module

[Peng Yu]

On Mon, Nov 2, 2009 at 7:11 AM, Peng Yu <pengyu.ut at gmail.com> wrote:
> On Mon, Nov 2, 2009 at 3:03 AM, Bruno Desthuilliers
> <bruno.42.desthuilliers at websiteburo.invalid> wrote:
>> Peng Yu a écrit :
>> (snip)
>>>
>>> I prefer organized my code one class/function per file (i.e per module
>>> in python). I know the majority of programmers don't use this
>>> approach. Therefore, I'm wondering what its disadvantage is.
>>
>> Hmmm... As far as I'm concerned, you already answered your own question:
>> "the majority of programmers don't use this approach".
>>
>> Now, for a much more practical answer:
>> 1/ having to handle thousands of files for even a simple project is a
>> king-size PITA for the maintainer.
>> 2/ having to load thousands of modules will add quite a lot of overhead when
>> actually running the code.
>> 3/ as a result, the poor guy that will end up maintaining your code will
>> positively hate you. Beware : this poor guy might as well be you.
>
> I still don't understand why it is a nightmare to maintain the code.
> For my C++ project, so far so good.
>
> I can easily change filenames (that is class name or function name), I
> can easily find them, I can easily move things around, all with just
> the corresponding script command. I can navigate to the definition of
> class and function by vim + ctags, I can see example code that calls
> the class/function. Whenever I suspect there is a bug, I can easily go
> to the right level of class/function in the directory hierarchy to
> write a test case to trace down the bug without having to use gdb.
>
> Would you please let me why it is a nightmare?

Another advantage one of class/function per file is that the syntax
clearly tell the dependence relation between classes and functions.

Suppose I have class A and class B in a file, I can not easily figure
out which class depends on which class by a simple script. However, if
they are in two separate files, for example B depends on A, then I
will have 'import A' in file B. This dependency can be easily figured
out by a script.

The following scenario also demonstrate why the maintenance cost is
lower with one class/function per file, because it decouples
dependences. Let's suppose class A and B are in the same file. Now I'm
changing class B. But while I'm changing class B, I just realize that
I have to change A. But since the change in B is half way done
(syntactical not correct), I will not be able to run the test case for
A, because the test case import the file that has class B. In
contrast, if A and B are in different files, even if B is half way
done, I can still run test case for A.