6

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?

Improve this question
4
  • 11
    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. Commented Jul 16, 2012 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 Commented Jul 16, 2012 at 21:53
  • 2
    'God File'... 'Ravioli Code'... when will this nonsense end? Commented Jul 17, 2012 at 13:16
  • Accepted concepts for this are Separation of concerns, modularity, coupling and Application logic. A "god" object is one that doesn't separate concerns and logics, ravioli code has hard to discern application logic, so discoverability is hard. Commented Sep 18, 2022 at 18:17

3 Answers 3

Reset to default
13

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.

Improve this answer
2
  • 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. Commented Jul 16, 2012 at 22:41
  • "emphasize it's logical structure" but the question is often which logical structure. God objects highlight application logic, how things are run, at the expense of separating different tasks. Hexagonal architecture is an example of somethingn that on the other hand separates logics (infrastructure, database, communication, business logic etc). Commented Sep 18, 2022 at 18:20
6

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.

              https://i.sstatic.net/jxR8c.gif

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.

Improve this answer
2
  • 1
    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. Commented Apr 15, 2016 at 8:14
  • "That leaves no chance for God files" I guess I would define "god objects" as application logic / plumbing files. I think sometimes the symptom of ravioli code sort of not having a separate space for mostly "application logic" which leads it to be diferent to find out what is going on. Commented Sep 18, 2022 at 18:23
0

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.

Improve this answer
4
  • Hmm... I think the issue with God files is more about separation of concerns than nagivation. Commented Sep 18, 2022 at 18:41
  • @AttRigh And at the end of the day separation of concerns has nothing to do with navigation? Commented Sep 19, 2022 at 14:08
  • if you can't work out what a function does, or how it related to the application as a whole, or the user interface then navigating code is quite hard. I mean... you can jump around quite well and search, but it won't necessarily mean much to you. Commented Sep 19, 2022 at 14:29
  • Yes, at the end of the day it comes down to navigation, because both codes function the same, that's what I'm saying. Commented Sep 19, 2022 at 17:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.