Opinions please -- how big should a single module grow?
in [Python]
|
Prev: cheap sale NBA caps and hats ( www.nike-black.com )
Next: Inheriting from "dict" (was: Python dynamic attribute creation)
From: Tomasz Rola on 9 Jul 2010 08:41 On Fri, 9 Jul 2010, Steven D'Aprano wrote: > This is a style question rather than a programming question. > > How large (how many KB, lines, classes, whatever unit of code you like to > measure in) should a module grow before I should break it up into a > package? I see that, for example, decimal.py is > 3000 lines of code, so > I can assume that 3 KLOC is acceptable. Presumably 3000 KLOC is not. > Where do you draw the line? > > For the purposes of the discussion, you should consider that the code in > the module really does belong together, and that splitting it into sub- > modules would mean arbitrarily separating code into separate files. Myself, I would draw "the line" somewhere between 20-50 KLOC&C (code with comments) - if something takes a lot of place to comment, then maybe it should go to a separate unit. As of the other side of scale, this 3000 KLOC thing, I believe you would have encountered a performance hit. And probably a big one - I would be afraid of some O(n^2) dragon or something bigger, waiting deeply in CPython code to eat your performance. But, I am just fantasizing - I have no idea of CPython internals and how big is the biggest Python code written so far. Python code tends to be very concise, so 3 MLOC sounds rather extremal to me. On the other hand, it is possible nobody tested CPython for such extreme case. Speaking of performance, there is also target user, and her needs (CGI? desktop? etc). So I would take this under consideration, too - how many times per second (minute, day) this code will be executed? Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola(a)bigfoot.com **
From: Tomasz Rola on 9 Jul 2010 11:21 On Fri, 9 Jul 2010, Tomasz Rola wrote: > On Fri, 9 Jul 2010, Steven D'Aprano wrote: > > > This is a style question rather than a programming question. > > > > How large (how many KB, lines, classes, whatever unit of code you like to > > measure in) should a module grow before I should break it up into a > > package? I see that, for example, decimal.py is > 3000 lines of code, so > > I can assume that 3 KLOC is acceptable. Presumably 3000 KLOC is not. > > Where do you draw the line? > > > > For the purposes of the discussion, you should consider that the code in > > the module really does belong together, and that splitting it into sub- > > modules would mean arbitrarily separating code into separate files. > > Myself, I would draw "the line" somewhere between 20-50 KLOC&C (code with > comments) - if something takes a lot of place to comment, then maybe it > should go to a separate unit. I meant 2-5 KLOC&C. Oups... Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola(a)bigfoot.com **
From: Martin P. Hellwig on 9 Jul 2010 12:03 On 07/09/10 05:37, Steven D'Aprano wrote: > This is a style question rather than a programming question. > > How large (how many KB, lines, classes, whatever unit of code you like to > measure in) should a module grow before I should break it up into a > package? I see that, for example, decimal.py is> 3000 lines of code, so > I can assume that 3 KLOC is acceptable. Presumably 3000 KLOC is not. > Where do you draw the line? > > For the purposes of the discussion, you should consider that the code in > the module really does belong together, and that splitting it into sub- > modules would mean arbitrarily separating code into separate files. > Personally I like to split up my module quite early and the main criteria is whether this improves (IMO) maintainability. So if I can refactor stuff that with some adaption can be used multiple times I put it in its own module. I rarely exceed 1KLOC per module and on average are on half of that. -- mph
From: Tomasz Rola on 9 Jul 2010 14:03 And just in case... A real life example (my computer, more or less typical Linux setup): find / -type f -name '*.py' -exec wc {} \; | gawk '{ l+=$1; } END {print l / FNR; } BEGIN { l=0; }' (the two lines should be concatenated) This gives a mean: 269.069 So, if I did not screw something, a typical Python code size is far below 1KLOC (wc counts all lines, so my result includes all comments and blanks too). Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola(a)bigfoot.com **
From: Paul Rubin on 9 Jul 2010 14:21
Steven D'Aprano <steve(a)REMOVE-THIS-cybersource.com.au> writes: > How large (how many KB, lines, classes, whatever unit of code you like to > measure in) should a module grow before I should break it up into a > package? I see that, for example, decimal.py is > 3000 lines of code, so > I can assume that 3 KLOC is acceptable. Presumably 3000 KLOC is not. > Where do you draw the line? I'd tend to say 2-4 KLOC, basically the max size in which it's reasonable to scroll through the file and read what it's doing, navigate around it with an editor, etc. Some exceptions are possible. |