Recently I asked a question about whether or not I should refactor my code. the responses I received were most definitely in the camp of going through with the refactoring due to the presence of a God File.

However, now I'm pushing towards what I fear is Ravioli code. I will have around 6-7 ".c" modules (which I find perfectly manageable), but I'm pushing in to having probably around 10~ ".h" headers.

I also still have about 8000 lines of code I need to parse through and refactor into their own parts and I'm not even sure how many more headers I'm going to need. I will probably be condensing and combining a few headers, but my question is:

What is worse from a software maintainability point of view, having potentially too many modules (making it difficult to find and change definitions) or averting previous problem by potentially having fewer files but have them be bloated with excessive functions? Is my problem inevitable due to the 12k+ lines of code? Or am I simply blowing the size of the system out of proportion?

  • 10
    Could you drop the buzzwords and pasta references and explain what you're really worried about? The humorously-named ravioli pattern isn't a real problem. – Caleb Jul 16 '12 at 21:32
  • 1
    I dont have any experience i c, but is 10+ header files really that bad? I am currently working on a big JavaScript project that has more than 20 .js files but I preffer many smaller files with well defined purposes than one huge file that tries to so everything. Many small files let me concentrate on one issue at a time, if each file has only one purpose – Charlie boy Jul 16 '12 at 21:53
  • 1
    'God File'... 'Ravioli Code'... when will this nonsense end? – James Jul 17 '12 at 13:16

What is worse from a software maintainability point of view, having potentially too many modules (making it difficult to find and change definitions)

This really isn't a problem. Any decent IDE is going to be able to immediately take you from an invocation to a definition, or from a definition to a list of all invocations. Even if you don't use an IDE, any decent editor is going to provide support for ctags or a similar tool.

I'd say organize your code to emphasize it's logical structure and to enforce separation of concerns.

  • 2
    I agree with this sentiment. The hallmark of a good design is that when bugs need fixing or features need to be added, it is pretty obvious where to make changes, and ideally these changes are well localized and easily tested. "Spaghetti code" is of course frowned upon for failing these expectations. – hardmath Jul 16 '12 at 22:41

There could be the cases when large files are preferable, most straightforward one being don't fix it while it ain't broken - 10K lines file that has no serious bugs reported against and no requests / plans to change may be well worth keeping alone.

Other than that, tie break in favor of things that occupy 2-3 or, better yet, 1 screen in your editor / IDE.

That leaves no chance for God files. 50 smaller files (by 50 lines each) may be difficult for code maintainer to find and change definitions but they at least could

  • list all 50 file names at one 1280x1024 screen and stare at these, and reason about these
  • show the contents of a particular 50-lines file at one screen and stare at it and reason about it

Guess what? maintainer could even experiment with merging 2-3 of such files into a bigger one to see if it improves understanding and even (magic!) split the merged files back if they find it's better to rollback.

As for the same amount of code - 50x50=2500 lines - even less than half of that - 1000 lines in a single file - there is no chance for maintainer to be able to stare at it and to reason about it.


One thing not to forget is that splitting code to smaller pieces won't automagically make it good.

One can have crappy code in 50 files by 50 lines each. Maintainer can look at particular 50 lines and realize these are crap. What maintainer can not though is to look at 1000 lines and realize anything - nothing at all.

50 files by 50 lines may be difficult but still manageable. 2500 lines are unmanageable and not just difficult - impossible to deal with.

  • I am not so sure that splitting into files make so much difference (if teh rest of the code is split sensibly). I have large models.py files in Django. Everything is split into classes (which could as easily have one file each). I don't think its any more difficult to navigate one large file with 20+ classes versus 20 files with one class each. – wobbily_col Apr 15 '16 at 8:14

It pretty simple. God Files are considered bad practice, because there is no conensus about an inexpensive way to navigate through those, such that you find your target code fast.

By splitting up your code into mulitple files you use a commonly well known an pretty inexpensive and fast way, which is supported by every IDE and that lets everybody find the desired code pretty fast.

When you develop your own way to navigate though a God File, probably also on the same level of expsiveness, it is still a problem for third parties looking at your code to navigate through it in the same way as you do, because they simply do not know your methodology.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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