Recommended way to modularize code in Arduino projects

What is the recommended way to modularize code in Arduino projects,

  1. Define all functions in the sketch file( the file contain setup() and loop())
  2. Declare functions in header files appropriately and definitions in .c then include in the sketch file( the file contain setup() and loop()) using #include
  3. Modularize as classes (in C++ way)

What is the recommended way to modularize code in Arduino projects,

  1. Define all functions in the sketch file( the file contain setup() and loop())
  2. Declare functions in header files appropriately and definitions in .c then include in the sketch file( the file contain setup() and loop()) using #include
  3. Modularize as classes (in C++ way)

Yes.

It depends on your goals. How much code do you want to share with other people? That does in a library (.cpp and .h file with classes, usually). How much code do you want to use in other projects, by copying files? That code would go in a .cpp (not .c, unless you are a masochist) file, with corresponding .h file, without the use of classes. If none of code will be reusable, it all goes in the .ino file (there can be more than one; the IDE will combine them all).

It depends on your goals. How much code do you want to share with other people? That does in a library (.cpp and .h file with classes, usually). How much code do you want to use in other projects, by copying files? That code would go in a .cpp (not .c, unless you are a masochist) file, with corresponding .h file, without the use of classes. If none of code will be reusable, it all goes in the .ino file (there can be more than one; the IDE will combine them all).

Ok, Is there any penalty in using 2 or 3 when compare to 1 in terms of efficiency and memory footprint? or the compiler has optimized to tackle such things?

PS: is there any documentation regarding which language feature are recommended to use ?

Is there any penalty in using 2 or 3 when compare to 1 in terms of efficiency and memory footprint?

No. Which you use depends on what you are comfortable with and what your goals are.

or the compiler has optimized to tackle such things?

Like a 500 pound linebacker.

Like a 500 pound linebacker.

XD

  1. isn't modular.
  2. compiles the same as 1) but separates code into separate .h files which can be
    reused with care.
  3. has overhead for class objects and method calls through objects, but it much more
    modular (easier to mix and match, share parts of the code as libraries).

As always the more functionality you want the more it costs...

  1. isn’t modular.
  2. compiles the same as 1) but separates code into separate .h files which can be
    reused with care.
  3. has overhead for class objects and method calls through objects, but it much more
    modular (easier to mix and match, share parts of the code as libraries).

As always the more functionality you want the more it costs…

make sense , many thanks for your reply . Does C++ 11 features are supported ?

Personally I would use .cpp files rather than .c ones.

Also I tend to take "black box" things that could be used elsewhere and turn them into small libraries. That way debugging a library (eg. a communications protocol, regular expression parser, LCD output) is done as a first step, and then the "main project" consists of assembling already-debugged parts.

Does C++ 11 features are supported ?

Not that I am aware of.

Also I tend to take "black box" things that could be used elsewhere and turn them into small libraries. That way debugging a library (eg. a communications protocol, regular expression parser, LCD output) is done as a first step, and then the "main project" consists of assembling already-debugged parts

.
for this process are you following option 2 or 3?

Both, they are not mutually exclusive. Except that I would put the .cpp and .h files into a separate folder and put that into the libraries folder (thus making a library). Then include the .h file in the main sketch.

If appropriate the library would have one or more classes in it.

Except that I would put the .cpp and .h files into a separate folder and put that into the libraries folder (thus making a library).

You don't move the .cpp and .h file to the libraries folder until the library has been tested as part of a sketch folder, do you? It's easier, I think, to be able to switch tabs in the IDE rather than open a separate text editor, when developing/debugging a library.

Once it does what it's supposed to, then moving the .cpp and .h files to the libraries directory makes sense.

True, there probably isn't much in it. I usually have some editor (Xcode happens to open on the Mac) for editing the library (has nice syntax colouring too) if my library has, er, bugs in it during development.

However your suggested technique of debugging the library (code) initially as part of the sketch is something that I usually do initially.

To be honest I usually do whatever takes the least work, as I am lazy. :wink: