Coding is fun for many developers, and as a coder, you are guaranteed never to be bored: every year, many new languages, technologies, frameworks, and libraries emerge.
Coders are a central part of any project; their contribution is crucial, and having good coders greatly increases the chances of a project succeeding.
But who qualifies as a good coder? Someone who writes a lot of code in a short amount of time?
Any developer knows that more code implies:
- more bugs.
- more code smells.
- more support.
- more documentation.
Each line of code can introduce a problem into the codebase and increase its technical debt. To reduce the number of bugs, it is generally better to have less code.
Let's take the bubble sort algorithm as an example: some developers may need 50 lines of code because they implement it from scratch, while others may need only two lines because they use a well-known library to do the job.
What's the big difference between coding from scratch and using a well-known, mature library?
A mature library has the following advantages:
- Used by thousands of developers.
- Very well tested.
- Ongoing evolution and compatibility with many operating systems are supported.
- Well optimized.
- Well documented.
- Maintained.
A good coder should be comfortable searching for existing solutions. Before implementing something complex, check whether a well-known library already does the job. In C++, as in other languages, there are many interesting libraries like STL, Boost, POCO...
In my experience as a developer, I have found that a good coder is someone who writes less code and works efficiently. This is not necessarily a technical guru with exceptional skills, but rather someone who knows how to search for and choose the right library for the job. Sometimes technical gurus tend to code from scratch, which can be harmful to the codebase quality.
But how do you choose the right library?
Choosing a software library is not always an easy task, especially if many competing libraries exist for a specific need. Many factors can influence a development team's choice of a library; here are some of them:
1. Licensing
The library license is the first thing to check. It is very important to verify that the license is compatible with how you intend to use the library in your project before going any further and exploring its capabilities.
http://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses
2. Does the library satisfy your needs?
It may seem obvious, but how many developers run a small proof of concept to check that the library meets all their needs? Sometimes we discover very early that the library is not suitable, for one reason or another.
3. The community is active
Many problems can occur when using a library; if its community is active, it will be very easy to find a solution quickly.
4. What is the library's adoption trend?
It's interesting to know if the library is growing in popularity or not. For that, you can use Google Trends and discover the evolution of the library over the years.
Here, for example, is the trend for the d3.js API:
5. Has the library had breaking changes in the past?
Before adopting a library, take a few minutes to search the web for “LibraryName breaking changes” to check whether a specific version introduced a breaking change.
This can help you for the following reasons:
- Avoid using library examples from older versions.
- A major breaking change can be a warning sign. It may indicate that compatibility with existing users is not a high priority, and similar changes could occur again in future versions.
6. Constraints and limitations of the library
Sometimes a library is excellent for a specific need but has one critical limitation that prevents you from using it.
Let's take the Google Chart API as an example: it's a very useful chart library. However, it has one annoying limitation — the user must have an internet connection.
Before choosing a library, make sure that none of its limitations could affect your use case. A simple web search for “LibraryName limitations” can help.
7. Documentation
A well-documented library will help you considerably when you use it, especially if it contains many usage samples.
8. Do you care about performance when using the library?
If you plan to use a library in a context where performance is very important, do not rely solely on benchmarks found on the web. It is better to build a proof of concept using your specific constraints to get a clearer idea of how the library performs in your context.
9. Is your application multiplatform?
If your application must run on multiple platforms, do not test primarily on one platform and wait until development is complete to test the others.
Always test from the beginning on all the targeted platforms; some libraries are very well implemented for one OS and very badly implemented for the others.
10. Is there any other serious alternative to the chosen library, and you have doubts?
In some cases, you may find two excellent libraries that meet the same needs and have difficulty choosing between them. In this case, never let your code be highly coupled with the library. Prefer using wrappers and facade patterns to isolate its use.
Of course, many other factors can influence your choice. To minimize the risk of adopting a library that may need to be replaced later, it is good practice to isolate its use to a few places in the code by using wrappers and facades.
Try to evaluate the coupling of your application with all the libraries used, identify the libraries highly coupled with your code, and progressively try, as much as possible, to decouple their use.
Many tools can be used to easily detect the coupling of external libraries. We can enumerate JDepend and JArchitect for Java, CppDepend for C/C++ and NDepend for .NET.