Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
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
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
'God File'... 'Ravioli Code'... when will this nonsense end? – James Jul 17 '12 at 13:16
up vote 12 down vote accepted

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.

share|improve this answer
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.

share|improve this answer
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 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 at 8:14

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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