How to Organize Arduino Code with Functions

A sketch that does everything inside loop() quickly becomes difficult to read and even harder to debug. As you add features, the loop grows longer, variables interact in unexpected ways, and finding the source of a bug means reading through pages of code.

This is where functions come in. By breaking your code into named blocks, each dedicated to a single task, you make your program much easier to manage. If a chunk of code reads a sensor, blinks an LED, or does a math calculation, it belongs in its own function. A descriptive function name makes your main loop read like a clear checklist of instructions rather than a messy jumble of code.

Using functions isn't a new concept—it goes back to the 1950s when Fortran introduced subprograms to replace repetitive blocks of code. Later, in the 1970s, computer pioneers like Edsger Dijkstra championed this approach as a cornerstone of clean, structured programming. In the Arduino world, you are already using functions from day one; every single sketch relies on setup() and loop(). The Arduino IDE requires these two, but you are free to build as many custom functions as your project needs.

Writing Functions

A function declaration in Arduino has four parts: the return type, the name, the parameters, and the body. The return type is the data type of the value the function sends back. If the function does not return a value, the return type is void. The function name should describe what the function does. Parameters are values passed into the function for it to use. The body contains the code that runs when the function is called.

A simple example is void blinkLED(int pin, int delayTime), which takes a pin number and a delay time and turns the LED on, waits, turns it off, and waits again. After defining the function, you call it from anywhere in your sketch by writing blinkLED(13, 500).

Parameters are passed by value in Arduino C++, which means the function receives a copy of the value, not a reference to the original variable. Changes made to parameters inside the function do not affect the original variables in the calling code. This is important for preventing unintended side effects.

If you need to modify a variable inside a function, declare it as global or pass a pointer. For beginners, global variables are the simpler approach, but experienced Arduino programmers prefer passing parameters and returning values to keep functions self-contained and reusable.

Organizing by Purpose

A well-organized Arduino sketch follows a clear structure. The setup() function initializes pins, starts serial communication, and configures libraries. The loop() function calls other functions in order. Each additional function does exactly one thing. If a function is doing multiple things, split it into smaller functions.

A function called readTemperature() should read a sensor, convert the value, and return it. It should not also update an LCD display or log data to serial. Those tasks belong in separate functions called from the main loop. This separation makes each function easier to test independently and easier to reuse in other projects.

Functions also eliminate code duplication. If you need to blink an LED in five different patterns, you can write one function that takes the pattern parameters and call it five times with different arguments, instead of copying the same code five times. When you find a bug in the blink logic, you fix it in one place, and all five patterns are corrected automatically.

According to computer science principles, this is called the DRY principle, which stands for Do not Repeat Yourself. Functions are the primary mechanism for achieving DRY in Arduino code.

Scope and Global Variables

A variable declared inside a function is local to that function. It does not exist outside the function, and its value is lost when the function exits. A variable declared at the top of the sketch, outside any function, is global and accessible from every function.

Global variables are convenient but introduce risks. Any function can modify a global variable, which can lead to unexpected behavior when multiple functions read and write the same variable.

The Arduino environment uses global variables extensively for pin definitions and shared data, but it is good practice to limit globals to values that genuinely need to be shared, such as pin numbers, sensor thresholds, and timing intervals. Variables used only inside a single function should be declared locally.

Practical Example

Consider a sketch that reads a temperature sensor, displays the value on serial, and turns on a fan if the temperature exceeds a threshold. Without functions, the entire code lives in loop(): read the sensor, convert the value, print to serial, check the threshold, turn on the fan.

With functions, the same logic is divided into readTemperature(), logTemperature(), and controlFan(). Each function is short and focused. The loop() calls these functions and nothing else. If the display format needs to change, you edit logTemperature() without touching the sensor code. This modular approach makes the sketch easier to write, easier to debug, and easier to extend.

Return Values and Reusability

A function that returns a value gives you more flexibility than a function that only acts. For example, a function called readAverageSensor(int pin, int samples) can read an analog sensor multiple times, calculate the average, and return the result as an integer.

The caller can use the return value anywhere an int is expected: Serial.println(readAverageSensor(A0, 10)) prints the averaged reading directly. The same function can be called for different sensors on different pins without modification. Functions that return values are the building blocks of modular code. They let you write a calculation once, test it thoroughly, and then use it confidently in every project without revisiting the internal logic.

According to best practices in embedded programming, functions should be kept short enough to fit on one screen. If a function exceeds approximately 20 lines, consider splitting it into smaller helper functions.

Each helper function should have a name that clearly describes its purpose, and the main function should read like a sequence of steps implemented by calling the helpers. This makes the code self-documenting. A new reader can understand the overall logic by reading the function names, without needing to read the implementation details of every helper.