Arduino Style Guide for Creating Libraries

Learn how to write library APIs in an Arduino style.

This is a style guide to writing library APIs in an Arduino style. Some of these run counter to professional programming practice. We’re aware of that, but it’s what’s made it possible for so many beginners to get started with Arduino easily. So please code with these principles in mind. If you have suggestions on how to make Arduino libraries clearer for that core audience, please jump in the discussion.

Be kind to the end user. Assume you are writing an API for an intelligent person who has not programmed before. Come up with a clear mental model of the concept you’re working with, and the terms and functions you will use.

Match your API to the underlying capabilities. You don’t want to expose implementation details to the user but you also don’t want an API that suggests an inaccurate mental model of the possibilities. For example, if there are only a few possible options for a particular setting, don’t use a function that takes an int, as it implies you can use any value you want.

Organize your public functions around the data and functionality that the user wants. Quite often, the command set for a particular electronic module is overly complicated for the most common uses, or can be re-organized around higher level functionality. Think about what the average person thinks the thing does, and try to organise your API functions around that. Adafruit's BMP085 library is a good example. The

function performs all the necessary steps to get the final pressure. The library wraps this commonly executed series of functions into a high-level single command which returns the value the user's looking for in a format she expects. It abstracts away not only the low-level I2C commands, but also the mid-level temperature and pressure calculations, while still offering those mid-level functions as public functions for those who want them.

Use full, everyday words. Don’t be terse with your function names or variables. Use everyday terms instead of technical ones. Pick terms that correspond to popular perception of the concept at hand. Don’t assume specialized knowledge. For example, this is why we used

rather than
. Abbreviations are acceptable, though, if they’re in common use or are the primary name for something. For example, “HTML” is relatively common and “SPI” is effectively the name of that protocol (“serial-peripheral interface” is probably too long). (“Wire” was probably a mistake, as the protocol it uses is typically called “TWI” or “I2C”.)

Avoid words that have different meanings to the general public. For example, to programmers, an error is a notification that something happened. To the general public, errors are bad things.

When you have to use a domain-specific term, write a sentence or two describing it to the general public FIRST. You’ll likely come across a better term, and if not, you’ll have started the documentation on your library.

Document and comment as you go. When writing examples and documentation, follow the Writing Style Guide

Use the established core libraries and styles.

  • Use
    to read inputs, and
    to write to outputs, e.g.
    , etc.
  • Use the
    classes when dealing with byte streams. If it’s not appropriate, at least try to use its API as a model. For more on this, see below
  • For network applications, use the
    classes as the basis.
  • Use
    to initialize a library instance, usually with some settings. Use
    to stop it.
  • Use camel case function names, not underscore. For example, analogRead, not analog_read. Or myNewFunction, not my_new_function. We've adopted this from for readability's sake.

LONG_CONSTANT_NAMES_FULL_OF_CAPS are hard to read. Try to simplify when possible, without being terse.

Try to avoid boolean arguments. Instead, consider providing two different functions with names the describe the differences between them.

Don’t assume knowledge of pointers. Beginning users of C find this the biggest roadblock, and get very confused by

, so whenever you can avoid having them hanging out in the API, do so. One way is to pass by reference using array notation rather than
notation, for example.

1void printArray(char* array);

can be replaced by

1void printArray(char[] array);

Though there are some libraries where we pass pointers by using structures like const chars, avoid anything that requires the user to pass them. For example,rather than:

1foo.readAccel(&x, &y, &z);

use something like this:

1xAxis = adxl.readX();
2 yAxis = adxl.readY();
3 zAxis = adxl.readZ();

When using serial communication, allow the user to specify any

object, rather than hard-coding
. This will make your library compatible with all serial ports on boards with multiple (e.g., Mega), and can also use alternate interfaces like SoftwareSerial. The Stream object can be passed to your library's constructor or to a
function (as a reference, not a pointer). See Firmata 2.3 or XBee 0.4 for examples of each approach.

When writing a library that provides byte-stream communication, inherit Arduino's

class, so your library can be used with all other libraries that accept
objects. If possible, buffer incoming data, so that
immediately accesses the buffer but does not wait for more data to arrive. If possible, your
method should store data to a transmit buffer, but
must wait if the buffer does not have enough space to immediately store all outgoing data. The
function should be called while waiting.

Here are a few libraries that are exemplary from Adafruit. She breaks the functions of the devices down into their high-level activities really well.

This does a nice job of abstracting from the Wire (I2C) library:

The text of the Arduino reference is licensed under a Creative Commons Attribution-ShareAlike 3.0 License. Code samples in the reference are released into the public domain.

Suggested changes

The content on is facilitated through a public GitHub repository. You can read more on how to contribute in the contribution policy.


The Arduino documentation is licensed under the Creative Commons Attribution-Share Alike 4.0 license.