4

Most of my programming experience and learning so far has been focused on languages (C++, C#, Python, etc.) that feature tools for Object Oriented Design and other 'high level' organizational concepts. Many of these languages have pretty clear conventions when it comes to breaking up a project into modules (files, packages, libraries, etc.), and often these conventions are pretty closely connected to OO ideas. As such, I find that I get a little bit stuck when I start thinking about writing a program in a language that doesn't rely heavily on these concepts (in this case, C).

For example, in C++ and C# I'm very used to typically organizing my programs such that each class is a module. In C# it's usually one file per class, and in C++ it's usually one header file and one source file per class. Of course, there are times when it's helpful to break these conventions and there is some degree of personal preference, but this is close to what I would consider to be conventional.

I'm pretty new to Python, so I won't risk generalizing too much here. However, from what I've seen so far, it seems that it's a little bit more common to throw multiple classes and/or functions into a single module/file. It seems the rule of thumb here is that your program should be as modular as possible within reason, but if some piece of code doesn't make sense as a stand-alone unit for other users to import it probably shouldn't be put into a separate module. Regardless, it seems the convention here is a bit less 'conventional' and a bit more logical.

So, back to learning C, the language seems pretty flexible from a design and organizational standpoint and it doesn't seem to carry too many 'built-in' conventions or rules for how to go about making a well organized and modular program. Compared to C++, where I would usually start programming with a sort of 'top-down' approach which involves declaring various high level classes in separate files, I'm not really sure how to organize a C program..

Other than writing chaotic spaghetti code, here are two basic approaches to C that I know so far:

  • Libraries: Break highly related groups of data structures and functionality into a single, coherent library. For example, you might make a "math" library that defines various common constants like pi or e, defines useful structs for vectors and matrices, and has a gamut of useful functions like trig functions, matrix math, etc. This is simple and makes a lot of sense, but it also seems like it could quickly become messy from a maintainability standpoint. Any client that uses a simply library like this would have transparent access to various functions and structs, meaning that changes in the library are much more likely to break other pieces of code. This might work well for a math library where significant changes to the data and interfaces are uncommon, but I can imagine that complex and large programs that undergo frequent changes would be hurt by this style of organization.

  • Abstract Data Types: Break a group of code into two files, one (source/.c) containing function and struct definitions, and another (header/.h) that declares a subset of those functions as well as defining new types as pointers to those structs. This looks very familiar to me, and I'd say that it verges on being a kind of home made OOP. This creates abstraction and encapsulation like OOP are used to working with, and it seems like you could break a project into similar ADT units (dare I say classes) in a similar way to creating a C++ program (one pair of files per ADT). This seems to have most of the benefits associated with OOP, but also many of the drawbacks, including added complexity and tons of 'boilerplate' code. I understand this, and I think it's well within my comfort zone, but I feel as if I've heard equal amounts of advise for and against designing C programs in a somewhat OO fashion.

Because C is a very powerful and 'low level' language, it seems like you have all the tools to do basically whatever you want. But what are some of the core conventions and recommendations that C programmers use to design, organize, and write big projects? Are there some other useful approaches that I don't know about? What are the benefits and drawbacks to each of these organizational approaches? Do design approaches shift significantly depending on the context of the project (for example, considerations of embedded vs. kernel vs. user-space application development)?

Edit: Question seems to be against the rules. Moved to reddit. https://www.reddit.com/r/learnprogramming/comments/4o4kea/modularity_techniques_in_c/

MrKatSwordfish
  • 1,504
  • 5
  • 18
  • 30
  • 1
    Well-thought-out question, but this might border on "Too broad"... my opinion is not definitive though, so I'll wait to see what other people say. – Patrick Roberts Jun 14 '16 at 22:02
  • I don't know of any rule against developing C with an OOP style. After all, the stdio functions are written this way, as is the Linux kernel. – antlersoft Jun 14 '16 at 22:04
  • 3
    Another point is that this question may be more well suited for [Programmers StackExchange](http://programmers.stackexchange.com/). See their [list of topics](http://programmers.stackexchange.com/help/on-topic). – Patrick Roberts Jun 14 '16 at 22:05
  • 2
    Those last 4 questions are a style matter and largely of an opinion (and broad). Suggest another site. – chux - Reinstate Monica Jun 14 '16 at 22:06
  • If this were to be migrated to Programmers, perhaps you could narrow down your question to ask specifically something to the effect of "What are some common core conventions in C for modularization?" Find a wording that will help minimize opinionated answers, and hopefully next time you won't get shot down at the door. – Patrick Roberts Jun 14 '16 at 22:08
  • I'd gladly see answers to this question, but rules are rules - too broad / opinion based apply too well here. – Daniel Kamil Kozar Jun 14 '16 at 22:17
  • Alright, I'll take my question elsewhere. Sorry about that. – MrKatSwordfish Jun 15 '16 at 00:10

0 Answers0