I was always curious when programming of anykind either being arduino or not. Is the best way to separate the code into different tabs and reference it when need to when you are programming on the main tab or having everything in one main code? For me doing both ways it's hard trying to figure things out if all in one tab or multuple tabs. But I find it easier to have it kind of in different tabs better. What doesthe community think?
Joseph
The Arduino IDE is not the best code editor. It has no split window function, which makes it difficult to have everything in one tab, and a sketch with over 300 lines. I'm terribly lazy, when I write code, which prevents me from creating more tabs. And that's really stupid, because it's so much easier to have things separated in different tabs, like classes if you write C++.
When code is so big that one file gets confusing and cluttered then split it into different files. Typically one class per file. So e.g. everything to do with sensor type 1 in a file, sensor type 2 in another file, LED control in another file, etc.
I also like to have a PortPins.h file where the usage of each pin is defined. This may be trivial for small sketches, but when one is close to running out of pins, it makes it much easier to work out which pins are currently free. This is an example from a small(ish) classic Nano sketch I'm working on ATM
#ifndef PortPins_h
#define PortPins_h
// used by nano serial 0
// used by nano serial 1
// free 2
// free 3
// free 4
#define PIN_LED5 5
#define PIN_LED4 6
// Following is only for connecting directly to Nano without veroboard
#define PIN_LED_GND 7
#define PIN_LED3 8
#define PIN_LED2 9
#define PIN_LED1 10
// free 11
// free 12
// free 13
// free A0
#define PIN_BATTERY A1
// free A2
// free A3
// free A4
// free A5
// free analog only A6
#define PIN_MOTOR A7
#endif
@Johan_Ha I'm not lazy when it comes to doing things. However when it comes to learning how different code works or trying it for myself it's hard when everything is on one tab and part of the cde is reference half way down second part is way at the bottom. then I have to go back up and find other parts.
@Dave_Lowther I hear you on that. I'm working on a simple project myself. For fan control with temperature. And found throughting everything on a single tab is frustrating. I honestly didn't start using new tabs to do anything beause I didn't understand how to use tabs or how to include them in the main tab until recently. I'm still a little frustrated even when using tabs. But not as much as I did with everything on one main tab.
There is a post here somewhere maybe tutorials about code organization in the Arduino IDE environment. If it's just ino files, you need to understand how they are processed, it likely is not what you expect and although rare could cause issues. If you have a .h file then it is widely agreed ALL includes go there, all globals and a few other things, a one time include either via #pragma or #ifndef etc
I split the code in several tabs/locigal units. The larger the project becomes, the more often I'm using .h/.cpp instead of .ino and do the includes manually in the order I want them or to be able to make #includes in other tabs.
There are some sudies on this topic. In the end it turned out that programmers using spaces earn more money than programmers using tabs. Reason is that bigger projects & bigger companies have conservative coding guidelines that specify to use spaces while startups and small companies dont have these guidelines --> when you are free to use tabs, you most likely work in a place that pays less.
First, it's not a question of "Tabs" but of files. Second, if you're truly interested in writing modular, reusable code, don't use the Arduino multi-ino file method. It's brain-dead! The Arduino build system simply mashes them together into one large file before handing it to the compiler. That can cause unexpected problems because of the order they are mashed together.
The long-established technique is to use header files (.h) and source files (.cpp). It's critical that you understand which code elements go in each. See My Post #5 in this Thread for some basic guidelines.
makes sense to separate parts of code that have significantly different puposes
the following list the files and # of lines for a model RR signalling systems. pcRead.cpp handles debug/diagnotics thru the serial monitor. signMap.cpp contains data descriptions of the signals and signals.cpp the code (logic) for managing the signals.
separating the functions into separate files avoids skipping over code that is mature and not changing
204 eeprom.cpp
376 i2c.cpp
236 pcRead.cpp
169 sigMap.cpp
375 signals.cpp
232 wifi.cpp
72 Node2.ino
1664 total
Thank you all @Johan_Ha @zwieblum @noiasca @sonofcy @gcjr and @gfvalvo The help and understanding how to structure things the correct way. The way I have been doing things besides the libraries in there own files and folders I have been putting things In a single file and over time it been like Now where did I put that fan control where it controls the PWM when the temperature gets above 30c or something else like that.
Joseph
Even on small, non-pro, "hello_world" sketches, modules allow for adding and removing features... and re-using functions, if you structure your archives right.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.