God Files versus Ravioli Code

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?

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.

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 1280×1024 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 – 50×50=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.

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.

Filed under: softwareengineering - @ 15:16

Thẻ: anti-patterns, design, design-patterns, maintainability

Thiết kế website giá rẻ

Danh mục

God Files versus Ravioli Code