You are not logged in.

#1 2020-05-24 14:50:37

Seadev
Member
Registered: 2020-05-24
Posts: 5

Why don't some C projects adopt modular programming?

I'm new to Arch and I've been slowly discovering the way you guys do things.

I recently wanted to edit some of the source code of DWM to give it my own personal touch. However, the entire program is just 2 .c files, both thousands of lines long. I was recommended FrankenWM by a friend, but when I look at the source code I see the same thing: 1 file, 3.7k lines of code.

Is there a reason for this? I just don't understand how you could easily navigate through code like that.

Offline

#2 2020-05-24 15:42:10

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 23,727
Website

Re: Why don't some C projects adopt modular programming?

In reply to your title, define 'modular'?  What should make different parts of a program different modules?  There certainly are trade-offs, but what I'm getting at is your question seems to suggest that there is some concrete definition one could use for what should be in a module.  There isn't.

Seadev wrote:

I just don't understand how you could easily navigate through code like that.

Personally I find it much easier when a small program is in few (or only 1) source file*.  The code still has to be well organized, but it's much easier to move around in a file to find another function or to follow the flow of control than to have to have a dozen files open and always wonder (or grep for) which file actually contains the defintion you're looking for.

Again, there are definitely pros and cons and there is a lot of subjective preference.  Your preference certainly is allowed to differ.  But your question implies that one persons preference is in some objective way more right.

* as a corollary, it drives me absolutely bat-shit-crazy when I try to review code for a project that has dozens of source files most of which have only a dozen lines of code - especially when there is no actual modularity, e.g., these code files do not build compoents of the final software that could be either replaced or opted out of.  I usually give up and find some other code to work with.  This is substantially more pronounced in C++ ... one of the many reasons I prefer C.

Last edited by Trilby (2020-05-24 15:54:52)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#3 2020-05-24 16:06:16

Seadev
Member
Registered: 2020-05-24
Posts: 5

Re: Why don't some C projects adopt modular programming?

Trilby wrote:

In reply to your title, define 'modular'?  What should make different parts of a program different modules?  There certainly are trade-offs, but what I'm getting at is your question seems to suggest that there is some concrete definition one could use for what should be in a module.  There isn't.

I was referring to separating the functionality of a program into independent, interchangeable modules. Where each module is a separate file.

Trilby wrote:

But your question implies that one persons preference is in some objective way more right.

That's not what I meant at all. I'm just used to working with higher level programming languages, all projects I have contributed to have their code separated into separate files. All I said is that I don't understand how one can easily navigate through the codebase when it's all in one file. And I was wondering if perhaps it's somehow related to the way the C language works.

From what I understand so far it all comes down to personal preference.

I was also wondering how exactly you navigate through code like that, do you simply just scroll to the function you want to edit? Or do you memorize all function names within a project and just jump to them with a 'find' shortcut? Do you have some kind of helper window in your IDE that displays all function names within the current file?

Last edited by Seadev (2020-05-24 16:15:06)

Offline

#4 2020-05-24 16:14:54

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 23,727
Website

Re: Why don't some C projects adopt modular programming?

Seadev wrote:

I was referring to separating the functionality of a program into independent, interchangeable modules.

I know the definition of the word.  I was asking how you determine what goes into each module.

Seadev wrote:

all projects I have contributed to have their code separated into separate files.

And in many cases, that is the right thing to do.  Situation dictates.  Were those other projects much larger?  Did they have actually logically modular components?  The structure of code - including how many files it may be in - ideally would reflect and/or depend on the logic of the code.  It's not immediately obvious to me what distinct modules could be made out of a program like dwm.  One could very easily just split it artificially into multiple files and compilation units.  But splitting just for the sake of splitting is not wise.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#5 2020-05-24 16:29:12

Seadev
Member
Registered: 2020-05-24
Posts: 5

Re: Why don't some C projects adopt modular programming?

Trilby wrote:

But splitting just for the sake of splitting is not wise.

But what about splitting for the sake of organizing code. For example: iirc, the bar on on top in DWM is a child window the DWM's root window. Wouldn't it be better if all code related to that bar (Rendering, manipulation) was separated into a bar.c file? If you want to modify some code related to the bar you would simply go into the bar.c file instead of searching for the right functions within one huge main file.

One thing I also find annoying is: Let's say I have found a section in the code I want to edit, and I quickly want to take a peek of another section. I assume I would either have to memorize the names of the functions and jump to them with the 'find' shortcut, or have multiple windows open of the same file.

Trilby wrote:

And in many cases, that is the right thing to do.  Situation dictates

Also, isn't it better to always build your project with scalability in mind from the very beginning, even if you think it's not a big project? Because you often don't know exactly how big the project will actually end up being. You never know how much code someone will write on top of your initial project (As a fork).

Last edited by Seadev (2020-05-24 16:49:45)

Offline

#6 2020-05-24 16:35:57

koffeinfriedhof
Member
Registered: 2017-11-30
Posts: 55

Re: Why don't some C projects adopt modular programming?

Hi!

Seadev wrote:

I was also wondering how exactly you navigate through code like that…

Depending on your editing behaviour, there are some helpers you might use. Emacs and vim both have folding modes and split view, where you can read code on the one side and search for declaration/definition on the other side (including the use of the same file). Some editors provide a shortcut to search the definitions and another one to switch between definition and declaration, like e.g. QtCreator or KDevelop do.

Offline

#7 2020-05-24 16:47:16

Seadev
Member
Registered: 2020-05-24
Posts: 5

Re: Why don't some C projects adopt modular programming?

koffeinfriedhof wrote:

Hi!

Seadev wrote:

I was also wondering how exactly you navigate through code like that…

Depending on your editing behaviour, there are some helpers you might use. Emacs and vim both have folding modes and split view, where you can read code on the one side and search for declaration/definition on the other side (including the use of the same file). Some editors provide a shortcut to search the definitions and another one to switch between definition and declaration, like e.g. QtCreator or KDevelop do.

Thanks, I'll give them a look!

Offline

#8 2020-05-24 16:57:50

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 23,727
Website

Re: Why don't some C projects adopt modular programming?

Seadev wrote:

Also, isn't it better to always build your project with scalability in mind from the very beginning.

No, I don't think so.  Yours is a common view, and there's room for it, but I really don't think it's better.  Starting from that point invites feature creep and bloat.  Small software with a clearly defined purpose does not need to "scale".  While the philosophy is misused and abused, there is a philosophy of "do one thing and do it well" - I don't recall ever hearing a thought out software philosophy that says "prepare to do everything from day 1" ... certainly not in the *nix ecosystem.

Now I don't want to overstate my case.  My case is simply a reaction.  Building with scalability in mind is often wise for many projects.  But the question was is it better to always build with scalability in mind from the beginning.  To that I say definitely not.

Seadev wrote:

the bar on on top in DWM is a child window the DWM's root window. Wouldn't it be better if all code related to that bar (Rendering, manipulation) was separated into a bar.c file?

One could (try to) do that.  But that just passes the buck.  How do you really determine which code is for the bar and which is for other bits as there is a lot of overlap.  The bar in dwm is pretty tightly integrated into the whole.  This is not the case for many other window managers.  In fact in many other wms there may be a commonly used but not required bar that is a completely seperate program (e.g., lemonbar, and was that for bspwm? Then there's xmonad and it's seperate bar).  Dwm has more recently (not sure if this is still the case) split all the drawing functions out to a distinct module.  This made some sense, though I still didn't much like it.  It made sense as it was conceivable that there'd be another approach to drawing.  Perhaps there could be the x11 drawing module which one could replace with a cairo module, or a wayland module (not really sure if this actually makes sense for the example, but it's the idea that a module could be interchangeable).

Last edited by Trilby (2020-05-24 17:02:23)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#9 2020-05-24 17:19:17

Seadev
Member
Registered: 2020-05-24
Posts: 5

Re: Why don't some C projects adopt modular programming?

Alright, thank you guys for the info.

The conclusion I have come to is that both project structures (In one file and split) are fine. It truly comes down to personal preference as well as the situation. The ideal software developer would be able to work with both. I will try to find ways to make navigating through one-file code-bases an easier process for me.

Offline

Board footer

Powered by FluxBB