(original) (raw)

On Oct 25, 2012 2:06 AM, "Larry Hastings" <larry@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@python.org
\> http://mail.python.org/mailman/listinfo/python-dev
\> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
\>