What do YOU prefer all code in one file or mutliple files?

Hi everybody,

I'm currently writing a demo-code that shows how multiple ESP32-boards can exchange data using the ESP-NOW protocol. This is much more code than a "twenty-liner"

Some parts of the code always stay the same. Some other parts must be adapted if somebody wants to adapt the demo-code to his project. To make it easier to get an overview about where the code has to be adapted I'm thinking about putting the code that always stays the same in a second file. Both ways - all code in one file or code separated into mutliple files have their pro's and con's.

So I'm interested to read your opinion. What are the advantages / disadvantages of one/mutliple files for a sketch?

best regards Stefan

StefanL38:
So I'm interested to read your opinion. What are the advantages / disadvantages of one/mutliple files for a sketch?

My opinion -- see Reply #3 Here.

i thought it was the Page Jones(?) book on programming from the late 70s that discussed software modules. they described two terms: coherence and coupling.

they said a module should maximize coherence, there is a purpose to the module and it should contain everything uniquely associated with that purpose. In other words, the functionality for that purpose shouldn't be scattered

coupling is the interdependence of modules on one another, that there may be unavoidable dependencies.

they were realistic in saying to maximize coherence and minimize coupling because inevitably there are exceptions that require breaking these guidelines.

in the Unix Programming Environment, kernighan and pike describe how to create a small interpreted language in a single chapter entitled "Program Development". They build a non-trivial language in stages, showing explaining the use of make and yacc. Doing it in stages to show how to add and test features gradually.

in that chapter, i think they show a great example of object oriented coding (before the term became do prevalent) where they create a file that defines the data structures and routines to manage symbols. the necessary functions are exposed in a header file.

i think it exemplifies the coherence/coupling concept suggested by Page/Jones.

i would suggest multiple files based on the concepts above. Some files will rarely be modified avoiding the possibility of corrupting them and the multiple files encourage you to create code in modules, maximizing coherence.

Some parts of the code always stay the same. Some other parts must be adapted if somebody wants to adapt the demo-code to his project. To make it easier to get an overview about where the code has to be adapted I'm thinking about putting the code that always stays the same in a second file.

there are quite a few other examples with a dedicated file "config.h" which holds all the user settings. But in these cases there are more than 40 configurations (or at least configurations with a lot of comments).

In general I'm using tabs to split the code in logical parts, but for a "simple" demo programm I can't imagine, why this should be necessary.

Seems you should really write a library for the parts the user doesn’t need to modify.
Then supply an example sketch for the parts they do.

If the user is “including demo code in their project”, it’s no longer “demo code”.