7

Libraries: Write Once, Use

Anywhere
Developing an application will typically involve integrating many different functionalities into one
project. For example, if you consider a modern industrial application, it will often be a composite
of many different components from many different vendors. Writing custom code to properly in-
teract with all these third-party devices will, at the very least, be a daunting and time-consuming
task. At worst, it could be impossible to accurately figure out how third-party devices operate to
programmatically interact with them. To remedy this problem, the device manufacturer or other
parties will often create what are called libraries to integrate modules into a project.

Almost all modern software projects, whether traditional or industrial automation applications
such as PLCs or HMIs, use libraries. In fact, it is nearly impossible to build a modern application
of any kind without the assistance of libraries. Libraries are very powerful programming tools
that can drastically reduce the complexity of a project, as well as the overall development time
needed to pull the project off. To master libraries, we will explore the following:

• What is a library?
• Libraries versus frameworks
• Installing a library
• Using a library in Ladder Logic
• Distributing a library
• Guiding principles for developing a library

To round out the chapter, we’re going to create a simple library for a robot.
172 Libraries: Write Once, Use Anywhere

Technical requirements
As per all previous chapters, this chapter will require nothing special other than a copy of COD-
ESYS. If you have skipped ahead and have not read the past chapters, you will need to download
and install a copy of CODESYS.

The code for this project and all other examples can be found at the following URL: https://
[Link]/PacktPublishing/Mastering-PLC-Programming-Second-Edition/tree/main/
Chapter%207.

Investigating libraries
A library is a piece of software that is designed to provide functionality for another project. In
common programming lingo, a library is often called a dependency because the main program is
dependent on the code that resides in the software module. This may sound complex, but under
the hood, a library is a collection of function blocks and other attributes that are designed to cut
down on new code.

In a very basic sense, a library is a code module that can be imported into a project. These code
modules are used to help developers do many things, such as cut down on redundant code that is
used across different projects, reduce bugs, integrate niche functionality into a project, and much
more. Essentially, when you’re working on a project, you want to focus on accomplishing the
project. In other words, if you’re working on an industrial 3D printer that needs to read Comma
Separated Values (CSV) files, you want to focus on building the 3D printer, not on a program
that can read CSV files. This is where libraries come into play. Libraries allow you to add certain
functionality to your code without losing focus on the main project.

Common uses for libraries include the following:

• To cut development time by using prebuilt and tested code

• To interface with custom or proprietary components
• To augment existing code with niche functionality by using third-party libraries
• To easily distribute code to other developers
Chapter 7 173

As stated before, libraries are the backbone of any modern programming language. For many
programming languages, such as C++, libraries are required for any new application. For example,
for most C++ programs, the Standard Template Library (STL) must be imported to use many of
the basic features of the language. Libraries in CODESYS and other similar systems are a bit more
optional compared to languages such as C++; however, they are no less important. Libraries can
be responsible for several things, and some common examples include the following:

• Communicating with IoT devices

• Communicating with hardware interfaces
• Integrating machine learning/artificial intelligence
• Using communication protocols and conversions
• Interfacing with cloud service providers

There are many more uses for libraries. To get the most from libraries, there is a key distinction
that needs to be made between a library and what’s called a framework.

Libraries versus frameworks

In everyday programming lingo, the terms library and framework are used interchangeably;
however, the two terms refer to two different things. To be a quality programmer of any kind, it
is very important to understand the difference between the two types of modules. To begin this
exploration, we’re going to explore what a library is at a fundamental level.

Understanding libraries
As was alluded to earlier, a library is a code module that augments your code. In other words, a
library is a collection of prebuilt function blocks and attributes that your program can call. If
you were to view a library through the eyes of biology, a library can be thought of as a perfor-
mance-enhancing drug for athletes. A library does not require any specific structure and can be
used in any type of application. This is in contrast to the other type of code module, which is
called a framework.
174 Libraries: Write Once, Use Anywhere

Understanding frameworks
A framework is like the skeleton of a person or animal. The purpose of a framework is to provide
the necessary structure to ensure your program does a certain thing. For example, a common
application for a framework in a traditional app would be the Django framework for Python. This
framework essentially turns the Python language into a web server programming language. A
framework will provide all the necessary scaffolding for your program to do a certain task. Com-
pared to a library, a framework can restrict what you can and cannot do. Your custom code will
serve as little more than the necessary straps to ensure the framework’s tasks are carried out. A
common theme that you will hear when discussing frameworks with other developers is that the
framework will morph the language into what can be thought of as a derivative or flavor of the
primary language. Overall, where your code calls a library, a framework calls your code.

In terms of automation, you are much, much more likely to encounter a library than a framework.
Though you can, as we will see later on in the chapter, build your own custom library, you are
much more likely to import a library from a source. So, in the next section, we’re going to practice
importing a library into a program.

Importing a library
We have been using the term third-party library quite a bit. Generally, the context for the term,
at least for this book, is a library that is distributed by a person, organization, or so on. These
libraries can usually be downloaded from sources such as GitHub, vendor websites, or any other
download source.

In terms of PLC programming, many libraries come from a vendor. However, you can still get
libraries from sources such as GitHub. If you opt to use a library that you get from a source such
as GitHub, you must import it. To demonstrate this, we are going to use a custom library that has
one function block that consists of one method, which adds two numbers. This is a custom library
that was developed for this book. The library can be downloaded at the following link: https://
[Link]/PacktPublishing/Mastering-PLC-Programming-Second-Edition.

The library is named adderLib. For this example, you will need to pull down the library to your
development machine.
Chapter 7 175

Installing a library
The following are the steps necessary to install a library. The adderLib library is written using
CODESYS and will only work with that system. Also, the following steps are for CODESYS; if you
find yourself using a different development system, the steps may differ, but the spirit of the op-
eration will likely be similar. It is best to consult the documentation for the system of your choice.

Note

The library for this tutorial will be included in the GitHub repo; however, as new
versions of the system are released, it may be incompatible with the version you’re
using. If you find yourself with an incompatible version of CODESYS, skip to the
Using a library in Ladder Logic section of this chapter to build a library you can import.

The steps for importing a library in CODESYS are as follows:

1. Create a new project, click on the Tools menu, and select Library Repository…, as shown
in Figure 7.1:

Figure 7.1: Tools drop-down icon

176 Libraries: Write Once, Use Anywhere

When you click the icon from Figure 7.1, you will be met with a screen similar to this:

Figure 7.2: Library repository screen

2. Once you see this screen, click on the Install button. This will open a normal File Explorer
window.
3. Navigate to where you downloaded the library and select it.
4. Once you select the library, you must import it into the project. To import the library into
your project, click on Library Manager in the project tree.

Figure 7.3: Library Manager

Chapter 7 177

5. Once you see this screen, click on the Add Library button, as in Figure 7.4:

Figure 7.4: Add Library button

6. Expand the (Miscellaneous) dropdown and select the entry called adderLib:

Figure 7.5: Library selection

7. Once you select the library and click the OK button, you should be all set up.
8. To use the library, navigate to the PLC_PRG file and create the following variables:
PROGRAM PLC_PRG
VAR
Addition : additionFB;
Result : INT;
END_VAR

You will also require the following logic:

result := [Link](33,33);

When you run the application, you should see an output similar to the following:

Figure 7.6: Library output

178 Libraries: Write Once, Use Anywhere

This is a general way to install a third-party library. This library was written and demonstrated
in Structured Text. Just because a library is written in one programming interface doesn’t mean
you’re married to that language. In the next section we’re going to use a Structured Text library
in Ladder Logic

Using a library in Ladder Logic

It’s no secret that Ladder Logic (LL) still rules the automation programming world. Though
Structured Text (ST) is a vital language and is slowly taking over the automation programming
landscape, we still need to be able to integrate the two. For this example, we’re going to take a
library written in ST and use it in an LL program. To follow along, create a new Ladder project
and download and install the LadderAdderLib library that is included in the GitHub repo. You
will need to import it with the same steps that we used before.

The code for the library is simple. The project is simply a function block that adds two numbers
and has a method named diff that subtracts two numbers. The only attributes for the main
function block (AdderFB) are two input variables called a and b, and a third called sum. The code
for AdderFB is as follows:
FUNCTION_BLOCK AddFb
VAR_INPUT
a : INT;
b : INT;
END_VAR
VAR_OUTPUT
sum : INT;
END_VAR
VAR
END_VAR

While the logic is simply this:

sum := a + b;

For the diff method, the variables will be as follows:

METHOD PUBLIC diff : INT
VAR_INPUT
a : INT;
Chapter 7 179

b : INT;
END_VAR

The subtraction logic for this method will be this:

diff := a - b;

To use the library in the main or consumer project after you install and import it, simply use the
following variables:
PROGRAM PLC_PRG
VAR
adder : AdderFB;
diff : INT;
a : INT := 500;
b : INT := 100;
END_VAR

In the Ladder Logic section of the PLC_PRG file, navigate to ToolBox, add two Box components,
and configure them to match Figure 7.7:

Figure 7.7: Configured library function block

180 Libraries: Write Once, Use Anywhere

Once you have all that configured, run the project, and you should be met with the output in
Figure 7.8:

Figure 7.8: Library output

Now that we have a basic understanding of how to implement a library, we can create one our-
selves. To begin, let’s investigate the architectural principles of creating a library!

Guiding principles for library development

Developing an effective library can be tricky. Where you’ll have a clear-cut application in mind
when developing a PLC program for a machine, you’ll have to make certain assumptions when
developing a library. You will not know ahead of time who will use the library, how they will use
it, or what they will use it for. Hence, creating a good library can be a very tricky and daunting
task. There are no clear-cut ways to create a perfect library, but there are a few rules that I came
across that have helped me develop some decent ones in the past.
Chapter 7 181

Rule 1: Remember KISS

The first rule of any software project, especially a library, is to keep it as simple as possible. When
creating a library, you want to ensure that you’re following the KISS methodology. A complex
library can become impossible to use; therefore, it is imperative to ensure that the library is as
simple as possible. As we will see with Rule 3, a simple way to reduce the complexity of a library
is to employ the Façade pattern to hide complexity.

In terms of the KISS methodology for libraries, the following are a few guardrails to help keep it
simple!

• Single responsibility: Much like a function block, a library should do one thing and one
thing only. If you pack too much functionality into a library, that can make it very hard to
use. This means if you’re making a library for a motor drive, the library should only have
exposed functionality that supports operations to control the motor. Adding functionality
to support things such as temperature sensing or something else that isn’t motor control
into the library can complicate it beyond use.
• Remove useless functionality: A good cliche to remember is if you don’t use it, lose it. A
killer of any library is junk functions or function blocks that serve no real purpose. This
is a common problem for many libraries. Having useless or redundant attributes can kill
the usability of a library, as it can cause confusion about how to use it.
• Use reflective naming: Do not get clever with the names of attributes. Ensure that each
public attribute’s name clearly reflects what its purpose is. Going off the rails with a name
can cause a lot of confusion and overcomplicate the usage of the library.
• Limit dependencies: A library will often depend on other libraries to operate. These de-
pendent libraries are often referred to as transient or downstream dependencies. These
dependencies can pose many problems because the end user will need to have them for
the library to operate. This means that if the end user does not have access to the correct
transient libraries you used to create the module, it is essentially broken.

With this rule in place, we can move on to abstraction and encapsulation!

Rule 2: Abstraction and encapsulation

Going with the theme of removing the possibility for your end user to shoot themselves in the foot,
all of the function block attributes should be well encapsulated with a decent level of abstraction.
In short, when developing a library, it is very important to show the consumer the absolute min-
imum they need to use the module. My general rule of thumb for all attributes, especially ones
182 Libraries: Write Once, Use Anywhere

that are in a library, is if I’m not planning on calling it from outside the function block, it gets an
access specifier of PRIVATE.

Due to the nature of the library and the wide variety of applications, it is important to hide as
much of the inner workings as possible. Generally, I like to teach my students to write a program
for the most inexperienced person in the room. This principle is even truer in library develop-
ment. Expanding on my general rule, I usually tend to create what I like to think of as an entry
point for the methods. This entry point will have all the necessary arguments and return types;
however, if there is dependent logic that breaks my one-sentence rule, I will break that out into
other PRIVATE methods and use the entry point to orchestrate them. This will create a system
where an outside consumer will only have to make one call to accomplish a task. Sometimes this
will be possible, but other times it won’t. Regardless, in my experience, it is best to have a single
method call that can accomplish the task than to burden the end user with multiple other method
calls to accomplish the same task. This principle kind of leads to the concept of design patterns.

Note

This is a major reason why it’s important to think of abstraction and encapsulation
in terms of hiding function block components! It helps clear clutter.

Rule 3: Use the Façade pattern liberally

When it comes to library design, the most useful pattern, in my opinion, is the Façade pattern.
This pattern can greatly reduce the complexity of a library when it comes to its overall usage. For
example, if you’re working on a library for a robot, it may require a complex operation to start,
turn off, or operate the machine. Since the operations are complex, it can be very hard for the
programmer to remember the correct sequence to carry out a particular operation. This is where
the Façade pattern comes into play.

Consider the following pseudocode:

Function Block Starter
Method battery()
Method ledOn()
Function Block Twist
Method motorOn()
Method rotateMotor()
Chapter 7 183

For a program like this, all the methods will need to be called at some point to move the robot. As
can be deduced, this could be hard to pull off, especially when the operations are more intricate
and complex. The Façade pattern can be used to help alleviate some of the complexity. In short,
a Façade pattern could be employed, like the following:
Function facade:
Method turnOnRobot():
[Link]()
[Link]()
Method moveRobot():
[Link]()
[Link]()

With this setup, if the programmer needs to move the robot, all they have to do is call the
turnOnRobot method and then the moveRobot method. In other words, we went from needing
to call four methods to only two, which are easier to remember and use!

Rule 4: Documentation
You could develop the greatest library in the world; however, if it is not documented, it will be
about as good as useless. It is important to remember that a library is typically a compiled project,
and in many (especially older or simpler) systems, ordinary comments will not be visible to the
consumer. You must use other means to communicate to other developers how to properly use
the library. There are many ways to document the proper usage of a library, including custom
documentation such as PDFs, websites, GitHub pages, and so on. You can also provide documen-
tation in CODESYS itself.

There are a few things that must always be documented in a library, which are as follows:

• Library information: It is necessary to provide information on what the library is designed

to accomplish.
• Function blocks: You will want to provide a simple synopsis of the function block.
• Methods: You will want to provide a synopsis of what the method does and provide in-
formation such as return types and arguments.
• Variables: You will also need to document the exposed function block and method-level
variables. You will want to provide information on what the variables are meant for.
184 Libraries: Write Once, Use Anywhere

All these attributes can be easily documented in CODESYS with minimal effort. In terms of pro-
viding code documentation, there are many ways to document things; however, the syntax that
I usually gravitate towards is the following:

• Declaration header: Denoted with ///. The triple slash is typically the safest to use for
declaration headers because these comments will always show up in the documentation,
and by default, at a minimum, you want this feature notated. I also recommend keeping
these features to a one-sentence summary.
• Member/attribute header: Denoted with (*<comment>*), this is a way of creating a
multi-line comment, which is often useful if an in-depth explanation of the attribute is
needed. You can also use the standard //; however, to use either syntax, the system must
be configured to read them.

Note

I’ve never been a fan of using // in my documentation. I typically advise using mul-
tiline comments for attribute documentation because 1) it’s more flexible, and 2) it
makes it easier to write more detailed descriptions of the attributes.

To demonstrate this, let’s modify our example library.

Open the LadderAdderLib library project and modify the code to match the following:
///This function block adds numbers
FUNCTION_BLOCK AdderFB
VAR_INPUT
a : INT; (*Input 1 INT*)
b : INT; (*Input 2 INT*)
END_VAR
VAR_OUTPUT
sum : INT;
END_VAR
VAR
END_VAR
Chapter 7 185

Once you are done with that, import the library into an example project. When you do this, dou-
ble-click on the library in Library Manager, and you should be met with something similar to
the following:

Figure 7.9: Method documentation example

The takeaway from the screenshots is that the triple slash (///) will generate a general message
at the top. In other words, the triple slash is more of a general attribute description, while the
parentheses are used more for the general description of variables.

There are other ways to add documentation, such as putting logically related function blocks
into folders and documenting what the module(s) are meant to do. This is accomplished by
right-clicking the folder and then clicking on Properties, then finally, selecting Documentation,
which will render the following:
186 Libraries: Write Once, Use Anywhere

Figure 7.10: Folder documentation window

When you click the OK button, the documentation will be generated. As with the other meth-
ods, you will be able to view the documentation after the library has been imported. To view the
documentation, click the Library Manager icon again and click on the folder. You should see
something similar to the following screenshot:

Figure 7.11: Folder documentation

Chapter 7 187

The final aspect that needs to be documented is the general information about the library, or, as
is commonly known, metadata. To do this, you will click the Project Information section in the
library project area, which will generate a popup like the following:

Figure 7.12: Library documentation

Arguably, the two most important fields are the name and the version. The name is important for
obvious reasons; the end user needs to know what they’re working with. The other important
piece of information is the version number. Quality version numbers use a concept called semantic
versioning, which signals to the user if the version of the library they are using is compatible with
their system. Therefore, the next section is going to look at how to properly version your library.
188 Libraries: Write Once, Use Anywhere

Semantic versioning
One of the most important things you need to consider when developing a library is the version
number. Put simply, the version number should follow a <[Link]> scheme. This
scheme is called semantic versioning. The meaning of each part of the scheme is summarized
in Table 7.1:

Version components Meaning

Major Changes will break backward compatibility

Minor Changes will add backward-compatible features

Patch Changes are backward-compatible bug fixes only

Table 7.1: Semantic versioning scheme

Before we move on, it is important that you understand the principles that were explored in this
section. Developing a library for deployment is not like developing a normal program. Things
must be named, documented, and architected well. Above all else, the library must be easy to
use. Once you understand these principles and have a grasp on them, we can attempt to create
a simple library in our final project.

Final project: Building a custom library

For our final project, we’re going to build a library for a robot. This library is going to be simple
and easy to implement; however, the final aspect of the project will be for you to clean it up and
make it easy to use! Therefore, to begin, let’s explore the needed requirements.

Requirements
For this project, we are going to need a simple library that can perform the following functions:

• Home the motor

• Turn the motor on
• Turn the motor off
• Stop the motor
• Position the motor
Chapter 7 189

This will be a very simple library and will not require complex architecture. For a library as simple
as this, we don’t have to worry about complexities such as design patterns; however, the Façade
pattern can make the library easier to use. So, let’s break down the methods we will need:

• Zero: Will zero out the motor

• Home: Will return the motor to its home position
• Turn on the motor: Will zero out the motor and put the motor in a standby state
• Turn off the motor: Will zero the motor and turn the motor off
• Stop the motor: Will halt the motor without zeroing it out
• Position the motor: Will move the motor to a position

Implementation
The first thing we need to do is to create a new project; however, unlike creating a normal project,
we are going to do the following:

1. Select Libraries and Empty library, as in the following screenshot:

Figure 7.13: Library creation

190 Libraries: Write Once, Use Anywhere

There are other ways to create a library with a full structure, such as by selecting CODE-
SYS library. However, this option will give you a full project with potentially unnecessary
files and structure. You can opt to use this if you would like, but for now, use an empty
library to remove bloat.

2. After you complete that step, you should see a project tree like the following:

Figure 7.14: Library project tree

3. Next, right-click Final Project Library and add a function block named MotorControl
with the methods in Figure 7.16. Set the return type of all the methods to BOOL and the
access specifier to PUBLIC.

Figure 7.15: Library project tree

4. Now that we have all the methods set up, we can start implementing the code. The first
thing that we need to do is declare a variable that holds the motor’s positions. For this,
we will need to go into the MotorControl function block and set a variable, as in the
following code:
FUNCTION_BLOCK MotorControl
VAR_INPUT
END_VAR
VAR_OUTPUT
END_VAR
VAR
motorPosition : INT;
motorOn : BOOL;
END_VAR
Chapter 7 191

5. Next, we will implement the zero method with the following code:
motorPosition := 0;

6. This will be all that is required for this method, as no internal variables will be set.
7. Next, we will implement the turnMotorOn method with the following:
ZeroMotor();
motorOn := TRUE;

8. After you have set up the turnMotorOn function, we will now implement the turnMotorOff
method with the following:
ZeroMotor();
motorOn := FALSE;

9. stopMotor will consist of only the following:

motorOn := FALSE;

10. The homeMotor method is also quite simple. This method will turn the motor on if it is off
and then call the zeroMotor method. Once these operations are complete, the motor will
be shut down. To do this, implement the following code:
IF motorON = FALSE THEN
motorON := TRUE;
END_IF
ZeroMotor();
motorON := FALSE;

11. The next method to tackle is the positionMotor method, which will take in an argument
and set the motorPosition function block variable to it, as in the following code:
METHOD PUBLIC positionMotor : BOOL
VAR_INPUT
motorPos : INT;
END_VAR

The logic for this method is as follows:

motorPosition := motorPos;
192 Libraries: Write Once, Use Anywhere

12. Now that all the variables are set up, we will need to save the project as a compiled library.

Figure 7.16: Saving the library

13. When you save the library, you will be met with a Project Information screen, as in Figure
7.17. Input the following information from Figure 7.17 to save the library:

Figure 7.17: Information fields for the library

This will create the Project Information file. This file will hold the metadata for the
library. You can change the version number, name, or anything else by double-clicking
the file once it is created.

14. At this point, your library is now saved and ready to be imported, similar to how we did in
the Third-party libraries section. Once you import the library, you can modify the PLC_PRG
file with the following to consume the code:
PROGRAM PLC_PRG
VAR
motor : MotorControl;
END_VAR
Chapter 7 193

At this point, we should be able to access all the methods in the function block. For ex-
ample, we now have access to the following:

Figure 7.18: Library methods

To give our project a test drive, implement the following reference variable if you have not already
done so:
PROGRAM PLC_PRG
VAR
motor : MotorControl;
END_VAR

The motor variable is a simple object reference variable for the MotorControl function block in
the library. To test a few methods, we’re going to rig the PLC_PRG POU file with the following:
[Link]();
[Link](motorPos := 120);

When the code is run, you should get the following:

Figure 7.19: Outputs

In this example, we only called two of the library methods. We only called two to see it in action
and prove that it works.
194 Libraries: Write Once, Use Anywhere

Project improvements
The final project demonstrates that the code works; however, we did not document the library
members. Also, if a developer were to perform a task such as positioning the motor, they would
need to call multiple methods. For example, to position the motor correctly, they would likely
need to do the following:

• Call stopMotor if the motor is running

• Call homeMotor
• Call positionMotor to reposition it
• With the current setup, the library user would have to remember a bunch of steps each
time they need to position the motor. For this cleanup, do two things. First, document
what the methods do. Second, rework the library to use a Façade method to carry out the
described positioning operation.
• This exercise is meant to simulate real-world library development. To carry out this clean-
up, you need to assume that 1) you do not know who is going to use your library and 2)
you do not know how the library is going to be used. This means you must really gener-
alize your solution. When it comes to a task like this, there is no right or wrong solution.
Essentially, you can only do your best to make it as usable as you can for everyone.

Documentation hints
As part of your documentation challenge, ensure you’re following Rule 4 and have the following
covered:

• Ensure the purpose of your variables is clearly defined. For example, if they are inputs for
some numerical calculation, stipulate it.
• Define any return types and argument types. CODESYS does this automatically, but you
need to ensure you get in the habit of notating it in case you ever find yourself working
with a system that doesn’t.
• Describe your methods with a clear sentence and apply the one-sentence rule.
• Clearly denote what the function block does and how it should operate. Though it is not
totally necessary, some developers will list out the methods as well.

Now that you’ve made and cleaned up your revolutionary library, it’s time to share it with the
world. In the next section, we’re going to explore some common considerations that need to be
addressed before you ship your code!
Chapter 7 195

Distribution
If you were to ship a library like the one we just built, you would need to determine how you’re
going to share it. Typically, many developers will opt to deploy their code to a platform such as
GitHub. This will allow others to pull the project down and use it. This route assumes you’re
making your project free to use. Depending on how you set the project up, this route will also
allow others to contribute and work on the project with you.

Sometimes you can even sell your project. You can do this by creating a website and charging
users to download it. In some PLC ecosystems, you can even opt to deploy your code via official
channels. In many cases, you can distribute your project for free or for a charge. However, one
important aspect to consider when deploying your code is licensing.

Licensing
Another consideration that you must consider is licensing, as it will dictate how users will be
allowed to utilize the library. Licensing is very important whether you’re using or creating a
library. There are many different licensing types to choose from. Common licenses are MIT, BSD,
and Apache licenses.

If you opt to use a third-party library, you need to pay attention to the licensing agreement. Many
libraries and plugins are free to use; however, this may not mean that you can freely distribute
them. In other words, just because you don’t have to pay for a library, it doesn’t mean you can
use it in a product that you’re going to ship. This is an issue that is more related to traditional
programming languages, but can still bite you if you’re not careful.

As with many traditional programming languages, you can download third-party libraries from
vendor websites, GitHub, or anywhere else. From many downloadable sources, the plugin is free;
however, it will come with a license agreement that will tell you how you can use the library
and distribute projects that utilize it. For some licenses, you can do whatever you want to with
the library; for others, there are restrictions on modifications, while others are much stricter on
what you can and cannot do. It is wise to remember that there are many different interpretations
of free, and you would be well advised to understand the types of licenses the software you’re
employing has.
196 Libraries: Write Once, Use Anywhere

Summary
In this chapter, we explored libraries. We learned what they are, how to use them, what third
parties are, basic development principles, and so on. You should now be able to use libraries
from external sources or create your own. What you will find is that by using libraries, you can
truly port code to different projects that use a compatible system and cut down on your overall
development time and effort.

There are a lot more to libraries, such as namespaces and so on, that were not explored in this
chapter. A whole book could be dedicated to this subject. It is recommended that you explore
libraries more on your own. This chapter was just a crash course to get you familiar with the
concept and consumption of libraries.

The key to maintaining your library is version control. Whether you’re deploying through GitHub
or selling your project, you will need to keep it organized and versioned. In the next section, we’re
going to explore how to do this with Git!

Questions
1. What is a library?
2. Why is documentation important?
3. What are three common types of software licenses?
4. What are some good design patterns to use in a library?

Get This Book’s PDF Version and

Exclusive Extras
Scan the QR code (or go to [Link]/unlock). Search for this
book by name, confirm the edition, and then follow the steps on
the page.

Note: Keep your invoice handy. Purchases made directly from Packt
don’t require an invoice.