I was browsing a github project and found this module which has more than 10 thousand lines.

Is it a common practice to have that much code in a single module?

It seems to me that this should be split over multiple modules. Maybe one for each db engine.

What benefit does the developer get from making one huge module like this (other than "having it all in one place") or what downside is there from splitting it up (other than "complexity")?

closed as primarily opinion-based by user40980, user53019, Kilian Foth, Bart van Ingen Schenau, jwenting Aug 4 '14 at 10:24

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Not 8k lines - for sure! – BЈовић Mar 15 '12 at 12:42
  • 4
    It's not the size of the module, it's how you use it... – jmq Mar 15 '12 at 14:13
  • 4
    Programs are meant to be read by humans and only incidentally for computers to execute -- Donald Knuth. – Mahmoud Hossam Mar 15 '12 at 20:08
  • 1
    A module/submodule is supposed to do one particular things. A (silly) module to add 2 numbers in Python would be 2 lines only. A module to do something more complicated will definitely be bigger. I say restrict the module/submodule to one function only. Kepp that as your benchmark. – c0da Mar 16 '12 at 9:36
  • By far the more important point for object-oriented code is to have a well organized class structure with separation of concerns and extreme dryness. Splitting the module then is the easy part. – Acumenus Mar 4 '14 at 5:04

What you encountered is the so-called "God object", because it does all or knows all. Run away from it (if you can).

There isn't a definite number of LOC per module, but it should be something that makes it easy to browse the code and easily understand what the methods are doing. From my personal experience, if your module goes beyond 1k lines*, you are doing something wrong.

* Even a 1k line module is very big.

  • 9
    The example given is not a God Object, it's actually a whole class hierarchy, including it's doctest, that just happens to be in a single .py file. This may not be ideal, but there are pragmatic reasons you might want to do this and as BillThor suggests, the code itself is otherwise reasonably well structured. It certainly doesn't fit the classic definition of a God Object, just one that has a fairly complex job to do and needs to be adaptable to a number of different scenarios. – Mark Booth Mar 16 '12 at 13:04

This appears to be a module where typical size limits may not apply. The majority of the functionality is in the first 2k lines of code and comments. The rest of the file appears to be a lot of adapter classes and other support classes which appear to be tightly coupled to the module. In other languages the classes would be in separate files of a reasonable size.

Some more doc strings might be useful, but they would increase the size of an already large module. The code is clear and self explanatory with appropriate comments where needed.


Of course the actual "limit" varies by your project and a multitude of factors.

But I chime in with a rule of thumb: 200 lines of decent Python. That is, no C or Java code written in Python, but good Python in Python.



I guess I don't know the full answer for this one, but I like thinking as an answer to the title question "How large should a Python module be?" as the concept of Parnas, hiding a secret. In this case the module seems to do that properly (and thats such a big secret it hides).

I've been digging into papers later that talk about a lot regarding coupling and cohesion. Maybe having many db modules would force too many calls between modules leading to increase what is considered bad practice, that is, lower cohesion and higher coupling?

I've seen experimental data talking about programmers deciding to sacrifice good practice for the sake of simplicity and understanding despite whatever good practice dictates. In fact, there could be a conflict between good practices as well. Say, performance doesn't usually makes the people who do maintenance happy later. I'm not quite sure how legibility would be improved in this case with such a big module.

Another thing I noticed is that part of the code is stated as generic and the rest of the dbs are extended from it. I'm not a python programmer, but perhaps this could justify something?

So, I don't have a final answer, but I hope someone highlights these points too!

Not the answer you're looking for? Browse other questions tagged or ask your own question.