Im familiar with OOP (coming from C#, Swift, Obj-C) but I was just wondering if it is bad/good practice in C++ to separate methods/properties of large projects into separate .h files and include them in the main .ino file so I have access to them.
To me it seems to be a good approach as I can group methods/properties that belong to each other into separate files and keep the main .ino file slim and clean (if its nothing that definitely needs to be a class/object).
yes, it is the same as for C++ development. ino is at build converted to a cpp file.
but it is also possible to use multiple ino files. is is less encapsulated, but you don't have to maintain the .h files. the ino files are at build concatenated and converted to one cpp file. (the concatenation ordering is the main ino file and then the rest is order by file name)
consider a program consisting of 10000 lines of code - do you
have a single file containing the 10000 lines of code
have multiple files (e.g. .h and .cpp) which break the program down into logical components which can be specified. implemented and tested semi-independently and built up into a complete system
do a web search on modular programming you will get plenty of links
I tend to have an .ino file containing setup() and loop() and the remainder of the code in .h and .cpp files.
write multiple ino files in the project directory (where the main file is the file that is named like the directory) and dont worry about to include them as they are included automatically by the compiler
write cpp and h files (separate definition and implementation) but not actually create a class but just a namespace
To split a large project into more managable pieces, right?
So this is actually a technique and nothing I have to worry about that it is bad practice to do so?