[Python-Dev] Split unicodeobject.c into subfiles

Nick Coghlan ncoghlan at gmail.com
Thu Oct 25 00:15:14 CEST 2012


On Oct 25, 2012 2:06 AM, "Larry Hastings" <larry at hastings.org> wrote:
>
> On 10/23/2012 09:29 AM, Georg Brandl wrote:
>>
>> Especially since you're suggesting a huge number of new files, I
question the
>> argument of better navigability.
>
>
> FWIW I'm -1 on it too.  I don't see what the big deal is with "large"
source files.  If you have difficulty finding your way around
unicodeobject.c, that seems like more like a tooling issue to me, not a
source code structural issue.

OK, I need to weigh in after seeing this kind of reply. Large source files
are discouraged in general because they're a code smell that points
strongly towards a *lack of modularity* within a *complex piece of
functionality*.

Breaking such files up into separately compiled modules serves two purposes:
1. It proves that the code *isn't* a tangled monolithic mess;
2. It enlists the compilation toolchain's assistance in ensuring that
remains the case in the future.

I find complaints about the ease of searching within the file to be
misguided and irrelevant, as I can just as easily reply with "if searching
across multiple files is hard for you, use better tools, like grep, or
'Find in Files'".

Note that I also consider the "pro" argument about better navigability
inaccurate - the real gain is in *modularity*, making it clear to readers
which parts can be understood and worked on separately from each other.

We are not special snow flakes - good software engineering practice is
advisable for us as well, so a big +1 from me for breaking up the
monstrosity that is unicodeobject.c and lowering the barrier to entry for
hacking on the individual pieces. This should come with a large block
comment in unicodeobject.c explaining how the pieces are put back together
again.

However, -1 on the "faux modularity" idea of breaking up the files on disk,
but still exposing them to the compiler and linker as a monolithic block,
though. That would be completely missing the point of why large source
files are bad.

Regards,
Nick.

--
Sent from my phone, thus the relative brevity :)

>
>
> /arry
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121025/355c2b2c/attachment.html>


More information about the Python-Dev mailing list