Coding is fun for many developers, and as a coder you are guaranteed to never be bored: each year many new languages, technologies, frameworks and libraries emerge.
Coders are the central piece of a project; their contribution is very important, and having good coders is a big guarantee of making a project a success.
But who can be qualified as a good coder? The one who codes a lot in a reduced time?
Any developer knows that more code implies:
- more bugs.
- more code smells.
- more support.
- more documentation.
Each line of code could introduce a problem in the codebase and increase its technical debt, and to have fewer bugs it's recommended to have less code.
Let's take the bubble sort algorithm as an example: some developers will need 50 lines of code because they code it from scratch, and some others need only 2 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.
- Evolution and compatibility with many OSes is guaranteed.
- Well optimized.
- Well documented.
- Maintained.
A good coder must be a Google friend, and before coding something complex, search if there's no known library doing the job. In C++, as in other languages, there are many interesting libraries like STL, Boost, POCO...
During my experience as a developer, I discovered that a good coder is the one who codes less and fast — and it's not necessarily a guru who has big technical skills, but the one who has the ability to search and choose the right library for the right job. Sometimes technical gurus tend to code from scratch, which can be harmful to the codebase quality.
But how to 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's very important to verify that the license is compatible with your usage in your project, before going further and discovering the library's capabilities.
http://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses
2. Does the library satisfy your needs?
It's a trivial factor, but how many developers run a mini proof of concept to check that all their needs are satisfied by the library? 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 about the trend of using the library?
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’s for example the trend of 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.
It could help you for the following reasons:
- Avoid using library examples from older versions.
- It's not a good sign if a library has a big breaking change. It means the developers don't care about the library users, and it could happen again in future versions.
6. Constraints and limitations of using a library.
Sometimes a library is awesome for a specific need, but has one killer limitation that could force you not to use 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, be sure that no limitation could affect its usage; you just have to search the web for “LibraryName limitations”.
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, don't only trust the benchmarks found on the web. It's preferable to make a POC with your specific constraints to have a better idea of how the library behaves in your specific context.
9. Is your application multiplatform?
If your application must work on many platforms, don't test mostly on one platform and then, after finishing development, test on all the other platforms.
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 could find two awesome libraries for the same needs, and you have doubts about using one of 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 there are many other factors that could influence your choice. And to minimize the risk of using a bad library that we must replace later, it's always a good practice to isolate its use in 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.